From pierre.francois@imdea.org Tue Nov 1 02:08:07 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2036121F8E08 for ; Tue, 1 Nov 2011 02:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.687 X-Spam-Level: X-Spam-Status: No, score=-0.687 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8iYhUGhWb-e for ; Tue, 1 Nov 2011 02:08:06 -0700 (PDT) Received: from estafeta.imdea.org (maquina44.madrimasd.org [193.145.15.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4661B21F8E03 for ; Tue, 1 Nov 2011 02:08:04 -0700 (PDT) Received: from localhost (estafeta22.imdea.org [172.17.99.146]) by estafeta22.imdea.org (Postfix) with ESMTP id 54D0C265470 for ; Tue, 1 Nov 2011 10:07:55 +0100 (CET) X-Virus-Scanned: by antispam-antivirus system at imdea.org Received: from estafeta.imdea.org ([172.17.99.146]) by localhost (estafeta22.imdea.org [172.17.99.146]) (amavisd-new, port 10024) with ESMTP id erR5BTrLq3H3 for ; Tue, 1 Nov 2011 10:07:55 +0100 (CET) Received: from dory.local (unknown [213.164.30.109]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pierre.francois) by estafeta22.imdea.org (Postfix) with ESMTP id B9A8526546E for ; Tue, 1 Nov 2011 10:07:54 +0100 (CET) Message-ID: <4EAFB6EF.1090601@imdea.org> Date: Tue, 01 Nov 2011 10:07:59 +0100 From: Pierre Francois User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 CC: 'IETF IDR' References: <056701cc97f7$416535d0$c42fa170$@com> In-Reply-To: <056701cc97f7$416535d0$c42fa170$@com> Content-Type: multipart/alternative; boundary="------------060307040200030906080904" Subject: Re: [Idr] FW: draft-keyupate-idr-bgp-gr-notification-00.txt - Adoption as working group draft X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 09:08:07 -0000 This is a multi-part message in MIME format. --------------060307040200030906080904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Support. Pierre. On 10/31/11 7:02 PM, Susan Hares wrote: > > Folks: > > The authors request the adoption of this draft. > > draft-keyupate-idr-bgp-gr-notification-00.txt > > Comments should be sent to the mailing group by November 15^th . > > Sue and John > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --------------060307040200030906080904 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Support.

Pierre.

On 10/31/11 7:02 PM, Susan Hares wrote:
draft-keyupate-idr-bgp-gr-notification-00.txt

Folks:

 

The authors request the adoption of this draft.

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

 

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

Sue and John



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

--------------060307040200030906080904-- From russw@riw.us Tue Nov 1 05:09:58 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBFA121F858C for ; Tue, 1 Nov 2011 05:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQdd4Wo0ccsL for ; Tue, 1 Nov 2011 05:09:58 -0700 (PDT) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 5FDE421F86D0 for ; Tue, 1 Nov 2011 05:09:58 -0700 (PDT) Received: from cpe-065-190-155-146.nc.res.rr.com ([65.190.155.146]:57140 helo=[192.168.100.51]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RLCIG-0001a9-4y for idr@ietf.org; Tue, 01 Nov 2011 07:14:12 -0400 Message-ID: <4EAFD47C.9050904@riw.us> Date: Tue, 01 Nov 2011 07:14:04 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: idr@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Subject: Re: [Idr] draft-keyupate-idr-bgp-gr-notification-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 12:09:59 -0000 Support. Russ On 10/31/2011 11:59 PM, Jeff Tantsura wrote: > Yes/support > > Regards, > Jeff > > On Oct 28, 2011, at 18:55, "Keyur Patel" > wrote: > > Hi Sue and John: > > We would like to request that the following draft be adopted as an IDR WG document: > > draft-keyupate-idr-bgp-gr-notification-00.txt > > It was presented at the IETF in Czech Republic. > > Regards, > Keyur > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From brian.peter.dickson@gmail.com Tue Nov 1 06:17:46 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5A211E80AA for ; Tue, 1 Nov 2011 06:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.543 X-Spam-Level: X-Spam-Status: No, score=-3.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P01402Da35u5 for ; Tue, 1 Nov 2011 06:17:45 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6D22711E8099 for ; Tue, 1 Nov 2011 06:17:45 -0700 (PDT) Received: by faas12 with SMTP id s12so7677227faa.31 for ; Tue, 01 Nov 2011 06:17:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ewFoP9Pndgl72vDPYaz8WL9kc9t9V6xBSP27NMFQYks=; b=XK2qYLdndzbhgeGo0Py4XEoyxNj9v8FxTQRyvvSfk4Dg0KiyX4SI34mueSqDaf/2lj PYn6bFmm0cPRXs6tGpMbacGxCbULAv9j6+HNateyH6xzVuNwEgNeBPhKMGqAA3VjOV4b N8HC1kZihm8a726jQDVhZTVYlitiXROxOjmWY= MIME-Version: 1.0 Received: by 10.223.1.12 with SMTP id 12mr592446fad.32.1320153463905; Tue, 01 Nov 2011 06:17:43 -0700 (PDT) Received: by 10.223.54.15 with HTTP; Tue, 1 Nov 2011 06:17:43 -0700 (PDT) In-Reply-To: <056701cc97f7$416535d0$c42fa170$@com> References: <056701cc97f7$416535d0$c42fa170$@com> Date: Tue, 1 Nov 2011 09:17:43 -0400 Message-ID: From: Brian Dickson To: Susan Hares Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF IDR , Susan Hares , "John G. Scudder" Subject: Re: [Idr] FW: draft-keyupate-idr-bgp-gr-notification-00.txt - Adoption as working group draft X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 13:17:46 -0000 Support. On Mon, Oct 31, 2011 at 2:02 PM, Susan Hares wrote: > Folks: > > > > The authors request the adoption of this draft. > > draft-keyupate-idr-bgp-gr-notification-00.txt > > > > Comments should be sent to the mailing group by November 15th. > > Sue and John > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > From rob.shakir@cw.com Tue Nov 1 06:23:03 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D73911E8148 for ; Tue, 1 Nov 2011 06:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xiFofzCuii7f for ; Tue, 1 Nov 2011 06:23:01 -0700 (PDT) Received: from service98.mimecast.com (service98.mimecast.com [195.130.217.59]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB8611E80C7 for ; Tue, 1 Nov 2011 06:22:58 -0700 (PDT) Received: from GBCWSWIEC002.ad.plc.cwintra.com (cmr2.cwplc.com [213.216.141.97]) (Using TLS) by service98.mimecast.com; Tue, 01 Nov 2011 13:22:56 +0000 Received: from GBVDCEM001.ad.plc.cwintra.com ([10.196.134.34]) by GBCWSWIEC002.ad.plc.cwintra.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Nov 2011 13:22:55 +0000 Received: from [10.144.134.16] ([10.144.134.16]) by GBVDCEM001.ad.plc.cwintra.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Nov 2011 13:22:55 +0000 Mime-Version: 1.0 (Apple Message framework v1084) From: Rob Shakir In-Reply-To: <056701cc97f7$416535d0$c42fa170$@com> Date: Tue, 1 Nov 2011 13:22:54 +0000 Message-Id: <32A23535-3110-47AC-9DCE-4E84D19C1F00@cw.com> References: <056701cc97f7$416535d0$c42fa170$@com> To: Susan Hares X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 01 Nov 2011 13:22:55.0486 (UTC) FILETIME=[5D9C89E0:01CC9899] X-MC-Unique: 111110113225608701 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Cc: 'IETF IDR' , 'Susan Hares' , "'John G. Scudder'" Subject: Re: [Idr] FW: draft-keyupate-idr-bgp-gr-notification-00.txt - Adoption as working group draft X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 13:23:03 -0000 On 31 Oct 2011, at 18:02, Susan Hares wrote: > Folks: > =20 > The authors request the adoption of this draft.=20 >=20 > draft-keyupate-idr-bgp-gr-notification-00.txt Hi Sue, John, IDR, I believe that this draft provides a means by which some of the requirement= s documented in the error handling requirements draft in GROW [0] can be me= t, I'd therefore support its adoption, and progression in IDR. Kind regards, r. [0]: http://tools.ietf.org/html/draft-ietf-grow-ops-reqs-for-bgp-error-hand= ling-02 This e-mail has been scanned for viruses by the Cable&Wireless Worldwide e-= mail security system. For more information on a proactive=20 managed e-mail secure service, visit http://www.cw.com/managed-exchange The information contained in this e-mail is confidential and may also be su= bject to legal privilege. It is intended only for the recipient(s) named ab= ove.=20 If you are not named above as a recipient, you must not read, copy, disclos= e, forward or otherwise use the information contained in this email. If you= =20 have received this e-mail in error, please notify the sender (whose contact= details are above) immediately by reply e-mail and delete the message and = any=20 attachments without retaining any copies. Cable & Wireless Worldwide plc=20 Registered in England and Wales. Company Number 07029206 Registered office: Liberty House, 76 Hammersmith Road, London W14 8UD, Engl= and From skh@ndzh.com Tue Nov 1 06:37:58 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD7A611E817A for ; Tue, 1 Nov 2011 06:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.163 X-Spam-Level: ** X-Spam-Status: No, score=2.163 tagged_above=-999 required=5 tests=[AWL=2.145, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aeeonfgzdziu for ; Tue, 1 Nov 2011 06:37:58 -0700 (PDT) Received: from hickoryhill-consulting.com (63-208-161-201.digitalrealm.net [63.208.161.201]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD3611E816E for ; Tue, 1 Nov 2011 06:37:57 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=50.84.54.50; Received: from SKHPERSONALLT (unverified [50.84.54.50]) by hickoryhill-consulting.com (SurgeMail 5.2a) with ESMTP id 2800899-1945496 for multiple; Tue, 01 Nov 2011 08:37:25 -0500 From: "Susan Hares" To: "'Rob Shakir'" References: <056701cc97f7$416535d0$c42fa170$@com> <32A23535-3110-47AC-9DCE-4E84D19C1F00@cw.com> In-Reply-To: <32A23535-3110-47AC-9DCE-4E84D19C1F00@cw.com> Date: Tue, 1 Nov 2011 09:37:30 -0400 Message-ID: <00f601cc989b$67a9b5f0$36fd21d0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-us Thread-index: AcyYmV+0PIDTCs2IQ2ardOdjbqeLsAAAd/XA X-Authenticated-User: skh@ndzh.com Cc: 'IETF IDR' , 'Susan Hares' , "'John G. Scudder'" Subject: Re: [Idr] Spam:*******, Re: FW: draft-keyupate-idr-bgp-gr-notification-00.txt - Adoption as working group draft X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 13:37:59 -0000 Rob: It is good to hear a confirmation for this draft draft-kayupate-idr-bgp-gr-notification. Could you also comment on draft-chen-error-handling-01.txt? Is this draft matching the error handling? Sue -----Original Message----- From: Rob Shakir [mailto:rob.shakir@cw.com] Sent: Tuesday, November 01, 2011 9:23 AM To: Susan Hares Cc: 'IETF IDR'; 'Susan Hares'; 'John G. Scudder' Subject: Spam:*******, Re: [Idr] FW: draft-keyupate-idr-bgp-gr-notification-00.txt - Adoption as working group draft On 31 Oct 2011, at 18:02, Susan Hares wrote: > Folks: > > The authors request the adoption of this draft. > > draft-keyupate-idr-bgp-gr-notification-00.txt Hi Sue, John, IDR, I believe that this draft provides a means by which some of the requirements documented in the error handling requirements draft in GROW [0] can be met, I'd therefore support its adoption, and progression in IDR. Kind regards, r. [0]: http://tools.ietf.org/html/draft-ietf-grow-ops-reqs-for-bgp-error-handling-0 2 This e-mail has been scanned for viruses by the Cable&Wireless Worldwide e-mail security system. For more information on a proactive managed e-mail secure service, visit http://www.cw.com/managed-exchange The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this email. If you have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any attachments without retaining any copies. Cable & Wireless Worldwide plc Registered in England and Wales. Company Number 07029206 Registered office: Liberty House, 76 Hammersmith Road, London W14 8UD, England From ju1738@att.com Tue Nov 1 08:21:06 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D045F1F0C3D for ; Tue, 1 Nov 2011 08:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.399 X-Spam-Level: X-Spam-Status: No, score=-105.399 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id es+nZInIPDWB for ; Tue, 1 Nov 2011 08:20:46 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 97F551F0C43 for ; Tue, 1 Nov 2011 08:20:46 -0700 (PDT) X-Env-Sender: ju1738@att.com X-Msg-Ref: server-7.tower-120.messagelabs.com!1320160788!46898265!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12323 invoked from network); 1 Nov 2011 15:19:48 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-7.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Nov 2011 15:19:48 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pA1FKFpJ011411; Tue, 1 Nov 2011 11:20:15 -0400 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (misout7msghub9a.itservices.sbc.com [144.151.223.62]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pA1FKDuk011332 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 1 Nov 2011 11:20:13 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([169.254.1.231]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.01.0339.001; Tue, 1 Nov 2011 11:19:45 -0400 From: "UTTARO, JAMES" To: "'Enke Chen'" Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-00 Thread-Index: AQHMkEAnLP0iAkRlVkChUYWtkZqOMZWKuQoAgAQhplCAAIdcwoABIPrwgAESmgCABpCw8A== Date: Tue, 1 Nov 2011 15:19:44 +0000 Message-ID: References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net> <4EA84254.9000400@raszuk.net> <4EA8A91C.4090305@cisco.com> <4EAA496C.9070605@cisco.com> In-Reply-To: <4EAA496C.9070605@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.84.170] Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550FA21F96MISOUT7MSGUSR9IIT_" MIME-Version: 1.0 Cc: "idr@ietf.org List" , "robert@raszuk.net" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 15:21:06 -0000 --_000_B17A6910EEDD1F45980687268941550FA21F96MISOUT7MSGUSR9IIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Enke, Comments in-Line.. Thanks, Jim Uttaro From: Enke Chen [mailto:enkechen@cisco.com] Sent: Friday, October 28, 2011 2:19 AM To: UTTARO, JAMES Cc: robert@raszuk.net; idr@ietf.org List; Enke Chen Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 Jim, My comments are inlined. On 10/27/11 1:17 PM, UTTARO, JAMES wrote: Enke, GR is a solution that is essentially local in scope it does not have the ab= ility to inform downstream speakers of the viability of routing state from = the point of possible control plane failure. OTOH Persistence does propagat= e the condition of state. This provides distinct advantages in terms of cus= tomers awareness of the SPs control plane. One could imagine a customer rec= eiving a STALE path and responding by selecting a backup. Some of the exten= sions to this draft that I have considered in colouring of STALE to inform = if the condition arises from a local ( PE ) or internal iBGP ( RR ) failure= s.. GR makes no distinction from STALE state and ACTIVE state.. This can lead t= o the STALE path still being preferred throughout the topology. IMO this is= incorrect behavior regardless of the comparison. PERSISTENCE allows for a customer to indicate which paths should be candida= tes. Customers may want to immediately failover to the backup for some path= s and not for others. GR is not capable of doing this it is all or nothing.= The granularity is not sufficient. It needs to be at the path level. There= may even be a case for having even more granularity i.e a per path timer..= GR is not capable of being extended for either of these cases. I am not sure how this path level persistence would work operationally. W= ithout the detailed information of a provider's network, how would a custom= er know what kind of failures and recovery that they might experience? Co= nsider the example of the simultaneous RR failures in the draft, why would dn't any customer not to want to protect against such failures? The end r= esult could be that the PERSISTENCE flag is always set, thus losing its sig= nificance. [Jim U>] One ex would be customers who create multiple VPNs over different = SPs.. A customer may want to take advantage of the knowledge that a control= plane failure has occurred and migrate the traffic to the backup. This cou= ld be done at a path granularity by use of the DO_NOT_PERSIST CV. . We as S= Ps want to provide our customers with the tools needed to manage their VPNs= and not prescribe a one size fits all solution. Regarding the use of the STALE state vs ACTIVE state, clearly there is a tr= adeoff. GR uses the stale routes in order to avoid forwarding churns, whi= ch has been a critical requirement for a long time. If there is a real ne= ed for favoring a ACTIVE one over a STALE one in GR, it can be done by a si= mple knob. [Jim U>] The current draft has no ability to inform downstream speakers of = whether or not a path is STALE or ACTIVE. The knob may be simple but a lot = of machinery would have to be built. This is one of the big reasons for the= PERSIST draft. I do not understand the routing churn part in the context o= f vpnv4, vpnv2, 3107 etc... maybe the GR solution was constructed as a solu= tion that primarily speaks to eBGP IPV4 connections for the IPV4 AF ( Inter= net ).. I could understand that.. As you know, BGP is full of knobs that adjust behaviors for different needs= :-) [Jim U>] More Knobs.. GR does not provide protection through successive restarts of the session. = I believe that if this occurs the state will be invalidated. So for a sessi= on that is bouncing due to overload condition GR will not provide the requi= red protection This can be addressed by a simple knob to set the min stale timer for GR. [Jim U>] And yet more knobs GR does not employ a make before break strategy. All state is invalidated f= irst then the newly learned state is processed. This leads to routing churn= especially if the majority of the state is the same which I am pretty sure= is the case Such behavior would be an implementation bug that needs to be fixed. But i= t is not an issue with the protocol itself. This is what we have in 4.2. Procedures for the Receiving Speaker, RFC 4724= : --- The Receiving Speaker MUST replace the stale routes by the routing updates received from the peer. Once the End-of-RIB marker for an address family is received from the peer, it MUST immediately remove any routes from the peer that are still marked as stale for that address family. [Jim U>] This does not address the lack of clarity about make before break.= . it only states that must immediately remove routes marked as stale. It sh= ould state that any paths that are learned which are the same as the STALE = paths should not force the forwarding plane to be re-programmed for those p= aths.. This should be made clear and in general is good practice to avoid c= hurn.. There are several possibilities for the premature purge of the stale routes= . For example, the "Forwarding state" flag was somehow not set after the se= ssion was re-established, or the the EOR was sent prematurely. Further in= vestigation will be needed in order to identify any possible implementation= or config issues involved in your setup. [Jim U>] More moving parts to worry about.. GR invalidates state due to the case of protocol error i.e A malformed upda= te will invalidate all of the state. This is not the desired behavior. It has been addressed by the following extension: http://datatracker.ietf.org/doc/draft-keyupate-idr-bgp-gr-notification/ [Jim U>] A few comments here.. I do not understand, the draft does not clar= ify that the only thing that will force a tear down is the cease subcode an= d a hard reset error code.. is the intention that this is the only thing th= at will tear it down? I guess I would like to see which things will and wil= l not force a session termination in the original draft.. Like - Holdtime Expiration - Malformed Update - Consecutive Restarts.. So what does this exactly mean "As part= of this extension, possible consecutive restarts SHOULD NOT delete a route (from the peer) previously marked as stale, until required by rules mentioned in [RFC4724]." Possible consecutive restarts= means what? I really need clarity on this whole notion of when is a sessio= n truly invalidated. Why is the purpose of the following text? Once the session is re-established, both BGP speakers MUST set their "Forwarding State" bit to 1 if they want to apply planned graceful restart. The handling of the "Forwarding State" bit should be done as specified by the procedures of the Receiving speaker in [RFC4724] are applied. GR is not specific as to which events invoke it or not. From my read on the= draft it is not clear if holdtime expiration invokes GR or not.. The draft= is unclear. I think that it is covered by the above extension. If not, it should be cl= arified. [Jim U>] I did not see it.. It is not clear to me how RRs and PEs differ in using GR. I think that there is a main difference when a RR is not in the forwarding = path. In that case, the RR should always set the F bit in the GR Capabilit= y so that its clients will continue forwarding after they lose the sessions= with RR. It is a deployment issue, though. [Jim U>] Yes.. Again from an operations perspective I have to deploy techno= logy differently in different parts of the network across multiple vendors.= This is generally not a desired starting point for the successful deployme= nt of new technology.. I want solutions that are generic and simple to depl= oy. The time that state can persist is limit to about 1 hour max. I think that you are talking about the "Restart time" field which has 12 bi= ts and amount to about 68 minutes. The "Restart time" is for the session r= e-establishment. It does not impact the duration for holding stale routes = after the session is re-established. [Jim U>] But if the session does not become re-established then the state = is invalidated as the session terminates with an error code that GR will no= t persist through.. If the session does not get re-established in 68 minutes, the stale routes = would be purged. That is a long time, isn't it? However, if one really w= ants to extend the session re-establishment time and continue to hold stale= routes, it can be done by a simple knob. [Jim U>] And yet even more knobs GR does detail the behavior where convergence is not achieved between resta= rts.. Similar to above.. The min stale timer knob can cover it (see above). But do you meant "does not"? We can certainly clarify in 4724bis if that i= s the case. [Jim U>] If convergence is not achieved what is the behavior. I could not d= etermine from the draft.. I do not believe that the current GR paradigm can be extended to cover the = majority of the cases above. Except for the path level persistence you mentioned, I believe the GR will = be able to address all other persistence requirements you listed, with some= simple knobs and some implementation enhancements. [Jim U>] IMO GR was originally designed to prevent churn due to intermitten= t failure on an eBGP session for the IpV4 AF.. I do not want to have differ= ent knobs and implementation enhancements to solve the basics of persistenc= e.. Regardless of that it does not inform the topology of the state of a pa= th in re the control plane it was learned over so there can be no independe= nt decisions about the value of a given path by different customers/provide= rs.. This is required for my applications.. Thanks, Jim Uttaro Thanks. -- Enke -----Original Message----- From: Enke Chen [mailto:enkechen@cisco.com] Sent: Wednesday, October 26, 2011 8:43 PM To: UTTARO, JAMES Cc: robert@raszuk.net; idr@ietf.org List; Enke Chen Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 Hi, folks: I have a hard time in understanding what new problems (beyond the GR) the draft try to solve :-( If the concern is about the simultaneous RR failure as shown in the examples in Sect. 6 Application, that can be addressed easily using GR. As the RRs are not in the forwarding path, it means that the forwarding is not impacted (thus is preserved) during the restart of a RR. The Forwarding State bit (F) in the GR capability should always be set by the RR when it is not in the forwarding path. Also in the case of simultaneous RR failure, I do not see why one would want to retain some routes, but not others, using the communities specified in the draft. As the RRs are not in the forwarding path, wouldn't be better to retain all the routes on a PE/client? As you might be aware, efforts have been underway to address issues with GR found during implementation and deployment. They include the spec respin, notification handling, and implementations. If there are issues in the GR area that are not adequately addressed, I suggest that we try to address them in the GR respin if possible, instead of creating another variation unnecessarily. Thanks. -- Enke On 10/26/11 10:24 AM, Robert Raszuk wrote: Jim, When one during design phase of a routing protocol or routing protocol extension or modification to it already realizes that enabling such feature may cause real network issue if not done carefully - that should trigger the alarm to rethink the solution and explore alternative approaches to the problem space. We as operators have already hard time to relate enabling a feature within our intradomain boundaries to make sure such rollout is network wide. Here you are asking for the same level of awareness across ebgp boundaries. This is practically unrealistic IMHO. Back to the proposal ... I think that if anything needs to be done is to employ per prefix GR with longer and locally configurable timer. That would address information persistence across direct IBGP sessions. On the RRs use case of this draft we may perhaps agree to disagree, but I do not see large enough probability of correctly engineered RR plane to experience simultaneous multiple ibgp session drops. If that happens the RR placement, platforms or deployment model should be re-engineered. Summary .. I do not think that IDR WG should adopt this document. Just adding a warning to the deployment section is not sufficient. Best regards, R. Robert, The introduction of this technology needs to be carefully evaluated when being deployed into the network. Your example clearly calls out how a series of independent design can culminate in incorrect behavior. Certainly the deployment of persistence on a router that has interaction with a router that does not needs to be clearly understood by the network designer. The goal of this draft is to provide a fairly sophisticated tool that will protect the majority of customers in the event of a catastrophic failure.. The premise being the perfect is not the enemy of the good.. I will add text in the deployment considerations section to better articulate that.. Thanks, Jim Uttaro -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: Sunday, October 23, 2011 5:32 PM To: idr@ietf.org List= Subject: [Idr] draft-uttaro-idr-bgp-persistence-00 Authors, Actually when discussing this draft a new concern surfaced which I would like to get your answer on. The draft in section 4.2 says as one of the forwarding rules: o Forwarding to a "stale" route is only used if there are no other paths available to that route. In other words an active path always wins regardless of path selection. "Stale" state is always considered to be less preferred when compared with an active path. In the light of the above rule let's consider a very simple case of dual PE attached site of L3VPN service. Two CEs would inject into their IBGP mesh routes to the remote destination: one marked as STALE and one not marked at all. (Each CE is connected to different PE and each PE RT imports only a single route to a remote hub headquarter to support geographic load balancing). Let me illustrate: VPN Customer HUB PE3 PE4 SP PE1 PE2 | | | | CE1 CE2 | | 1| |10 | | R1 ------ R2 1 CE1,CE2,R1,R2 are in IBGP mesh. IGP metric of CE1-R1 and R1-R2 are 1 and R2-CE2 is 10. Prefix X is advertised by remote hub in the given VPN such that PE1 vrf towards CE1 only has X via PE3 and PE2's vrf towards CE2 only has X via PE4. Let's assume EBGP sessions PE3 to HUB went down, but ethernet link is up, next hop is in the RIB while data plane is gone. Assume no data plane real validation too. /* That is why in my former message I suggested that data plane validation would be necessary */. R1 has X via PE1/S (stale) and X via PE2/A (active) - it understands STALE so selects in his forwarding table path via CE2. R2 has X via PE1/S (stale) and X via PE2/A (active) - it does not understand STALE, never was upgraded to support the forwarding rule stated above in the draft and chooses X via CE1 (NH metric 2 vs 10). R1--R2 produce data plane loop as long as STALE paths are present in the system. Quite fun to troubleshoot too as the issue of PE3 injecting such STALE paths may be on the opposite site of the world. The issue occurs when some routers within the customer site will be able to recognize STALE transitive community and prefer non stale paths in their forwarding planes (or BGP planes for that matter) while others will not as well as when both stale and non stale paths will be present. Question 1: How do you prevent forwarding loop in such case ? Question 2: How do you prevent forwarding loop in the case when customer would have backup connectivity to his sites or connectivity via different VPN provider yet routers in his site only partially understand the STALE community and only partially follow the forwarding rules ? In general as the rule is about mandating some particular order of path forwarding selection what is the mechanism in distributed systems like today's routing to be able to achieve any assurance that such rule is active and enforced across _all_ routers behind EBGP PE-CE L3VPN boundaries in customer sites ? Best regards, R. -------- Original Message -------- Subject: [Idr] draft-uttaro-idr-bgp-persistence-00 Date: Sat, 22 Oct 2011 00:23:55 +0200 From: Robert Raszuk Repl= y-To: robert@raszuk.net To: idr@ietf.org List Hi, I have read the draft and have one question and one observation. Question: What is the point of defining DO_NOT_PERSIST community ? In other words why not having PERSIST community set would not mean the same as having path marked with DO_NOT_PERSIST. Observation: I found the below statement in section 4.2: o Forwarding must ensure that the Next Hop to a "stale" route is viable. Of course I agree. But since we stating obvious in the forwarding section I think it would be good to explicitly also state this in the best path selection that next hop to STALE best path must be valid. However sessions especially those between loopbacks do not go down for no reason. Most likely there is network problem which may have caused those sessions to go down. It is therefor likely that LDP session went also down between any of the LSRs in the data path and that in spite of having the paths in BGP and next hops in IGP the LSP required for both quoted L2/L3VPN applications is broken. That may particularly happen when network chooses to use independent control mode for label allocation. I would suggest to at least add the recommendation statement to the document that during best path selection especially for stale paths a validity of required forwarding paradigm to next hop of stale paths should be verified. For example using techniques as described in: draft-ietf-idr-bgp-bestpath-selection-criteria Best regards, R. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_B17A6910EEDD1F45980687268941550FA21F96MISOUT7MSGUSR9IIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Enke,

 

          =       Comments in-Line..

 

Thanks,

          =       Jim Uttaro

 

From: Enke Chen [mai= lto:enkechen@cisco.com]
Sent: Friday, October 28, 2011 2:19 AM
To: UTTARO, JAMES
Cc: robert@raszuk.net; idr@ietf.org List; Enke Chen
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00

 

Jim,

My comments are inlined.

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

Enke,
 
GR is a solution that is essentially local in scope it does not have t=
he ability to inform downstream speakers of the viability of routing state =
from the point of possible control plane failure. OTOH Persistence does pro=
pagate the condition of state. This provides distinct advantages in terms o=
f customers awareness of the SPs control plane. One could imagine a custome=
r receiving a STALE path and responding by selecting a backup. Some of the =
extensions to this draft that I have considered in colouring of STALE to in=
form if the condition arises from a local ( PE ) or internal iBGP ( RR ) fa=
ilures.. 
 
GR makes no distinction from STALE state and ACTIVE state.. This can l=
ead to the STALE path still being preferred throughout the topology. IMO th=
is is incorrect behavior regardless of the comparison. 
 
PERSISTENCE allows for a customer to indicate which paths should be ca=
ndidates. Customers may want to immediately failover to the backup for some=
 paths and not for others. GR is not capable of doing this it is all or not=
hing. The granularity is not sufficient. It needs to be at the path level. =
There may even be a case for having even more granularity i.e a per path ti=
mer.. GR is not capable of being extended for either of these cases.


I am not sure how this path level persistence would work operationally.&nbs= p;  Without the detailed information of a provider's network, how woul= d a customer know what kind of failures and recovery that they might experi= ence?   Consider the example of the simultaneous RR failures in the draft,  why would

dn't any customer not to want to protect against suc= h failures?   The end result could be that the PERSISTENCE flag i= s always set, thus losing its significance.

[Jim U>] One ex would be customers who create multiple VP= Ns over different SPs.. A customer may want to take advantage of the knowle= dge that a control plane failure has occurred and migrate the traffic to the backup. This cou= ld be done at a path granularity by use of the DO_NOT_PERSIST CV. . We as S= Ps want to provide our customers with the tools needed to manage their VPNs= and not prescribe a one size fits all solution.



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

[Jim U>] The current draft has no ability to inform downs= tream speakers of whether or not a path is STALE or ACTIVE. The knob may be= simple but a lot of machinery would have to be built. This is one of the big reasons for th= e PERSIST draft. I do not understand the routing churn part in the context = of vpnv4, vpnv2, 3107 etc… maybe the GR solution was constructed as a= solution that primarily speaks to eBGP IPV4 connections for the IPV4 AF ( Internet ).. I could understand that..<= o:p>



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

[Jim U>] More Knobs..




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


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

[Jim U>] And yet more knobs




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


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

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

---

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

[Jim U>] This does not address the lack of clarity about = make before break.. it only states that must immediately remove routes mark= ed as stale. It should state that any paths that are learned which are the same as the STA= LE paths should not force the forwarding plane to be re-programmed for thos= e paths.. This should be made clear and in general is good practice to avoi= d churn..



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

[Jim U>] More moving parts to worry about..




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


It has been addressed by the following extension:

http://datatracker.ietf.org/doc/draft-keyupate-idr-bgp-gr-notifica= tion/


[Jim U>] A few comments here.. I do not understand, the d= raft does not clarify that the only thing that will force a tear down is th= e cease subcode and a hard reset error code.. is the intention that this is the only thing= that will tear it down? I guess I would like to see which things will and = will not force a session termination in the original draft.. Like

 

- =          Holdtime Expiration

- =          Malformed Update

=
-    &nbs=
p;     Consecutive Restarts.. So what does this exactly mean   “As part of this extension, =
possible consecutive restarts SHOULD NOT

   delete a route (from the peer) previously ma= rked as stale, until

   required by rules mentioned in [RFC4724].= 221; Possible consecutive restarts means what? I really need clar= ity on this whole notion of when is a session truly invalidated.=

 

Why is the purpose of the following text?<= /p>

 

   Once the session is re-established, both BGP= speakers MUST set their

   "Forwarding State" bit to 1 if the= y want to apply planned graceful

   restart.  The handling of the "For= warding State" bit should be done

   as specified by the procedures of the Receiv= ing speaker in [RFC4724]

   are applied.

 

 

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


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

[Jim U>] I did not see it..




 
It is not clear to me how RRs and PEs differ in using GR. <=
/pre>



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


[Jim U>] Yes.. Again from an operations perspective I hav=
e to deploy technology differently in different parts of the network across=
 multiple vendors.
 This is generally not a desired starting point for the successful deployme=
nt of new technology.. I want solutions that are generic and simple to depl=
oy.












 


 


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




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


[Jim U>]  But if the session does not become re-esta=
blished then the state is invalidated as the session terminates with an err=
or code that GR will
 not persist through..






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


[Jim U>] And yet even more knobs











 


 


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




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



But do you meant "does not"?  We can certainly clarify in 47=
24bis if that is the case.<=
/p>

[Jim U>] If convergence is not achieved what is the behav=
ior. I could not determine from the draft..











 


 


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




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



[Jim U>] IMO GR was originally designed to prevent churn =
due to intermittent failure on an eBGP session for the IpV4 AF.. I do not w=
ant to have different
 knobs and implementation enhancements to solve the basics of persistence..=
 Regardless of that it does not inform the topology of the state of a path =
in re the control plane it was learned over so there can be no independent =
decisions about the value of a given
 path by different customers/providers.. This is required for my applicatio=
ns.. 












 


 


Thanks,


        Jim Uttaro




Thanks.   -- Enke








 


 


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


From: Enke Chen [mailto:enkechen=
@cisco.com] 


Sent: Wednesday, October 26, 2011 8:43 PM


To: UTTARO, JAMES


Cc: robert@raszuk.net; idr@ietf.org List; Enke Chen


Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00

 


Hi, folks:


 


I have a hard time in understanding what new problems (beyond the GR) =



the draft try to solve :-(


 


If the concern is about the simultaneous RR failure as shown in the 


examples in Sect. 6 Application, that can be addressed easily using GR=
.  


As the RRs are not in the forwarding path, it means that the forwardin=
g 


is not impacted (thus is preserved) during the restart of a RR. &=
nbsp; The 


Forwarding State bit (F) in the GR capability should always be set by =



the RR when it is not in the forwarding path.


 


Also in the case of simultaneous RR failure, I do not see why one woul=
d 


want to retain some routes, but not others, using the communities 


specified in the draft.  As the RRs are not in the forwarding pat=
h, 


wouldn't be better to retain all the routes on a PE/client?=



 


As you might be aware, efforts have been underway to address issues wi=
th 


GR found during implementation and deployment. They include the spec <=
o:p>


respin, notification handling, and implementations.  If there are=
 issues 


in the GR area that are not adequately addressed,  I suggest that=
 we try 


to address them in the GR respin if possible, instead of creating 


another variation unnecessarily.


 


Thanks.   -- Enke


 


 


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




Jim,


 


When one during design phase of a routing protocol or routing protocol=
 


extension or modification to it already realizes that enabling such 


feature may cause real network issue if not done carefully - that 


should trigger the alarm to rethink the solution and explore 


alternative approaches to the problem space.


 


We as operators have already hard time to relate enabling a feature 


within our intradomain boundaries to make sure such rollout is network=
 


wide. Here you are asking for the same level of awareness across ebgp =



boundaries. This is practically unrealistic IMHO.


 


Back to the proposal ... I think that if anything needs to be done is =



to employ per prefix GR with longer and locally configurable timer. 


That would address information persistence across direct IBGP sessions=
.


 


On the RRs use case of this draft we may perhaps agree to disagree, 


but I do not see large enough probability of correctly engineered RR <=
o:p>


plane to experience simultaneous multiple ibgp session drops. If that =



happens the RR placement, platforms or deployment model should be 


re-engineered.


 


Summary .. I do not think that IDR WG should adopt this document. Just=
 


adding a warning to the deployment section is not sufficient.


 


Best regards,


R.


 


 




Robert,


 


The introduction of this technology needs to be carefully evaluated


when being deployed into the network. Your example clearly calls out


how a series of independent design can culminate in incorrect


behavior. Certainly the deployment of persistence on a router that


has interaction with a router that does not needs to be clearly


understood by the network designer. The goal of this draft is to<=
/o:p>


provide a fairly sophisticated tool that will protect the majority of<=
o:p>


customers in the event of a catastrophic failure.. The premise being


the perfect is not the enemy of the good.. I will add text in the=



deployment considerations section to better articulate that..


 


Thanks, Jim Uttaro


 


-----Original Message----- From: idr-bounces@ietf.org


[mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent:


Sunday, October 23, 2011 5:32 PM To: i=
dr@ietf.org List Subject: [Idr]


draft-uttaro-idr-bgp-persistence-00


 


Authors,


 


Actually when discussing this draft a new concern surfaced which I


would like to get your answer on.


 


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


 


o  Forwarding to a "stale" route is only used if there =
are no other


paths available to that route.  In other words an active path alw=
ays


wins regardless of path selection.  "Stale" state is al=
ways


considered to be less preferred when compared with an active path.


 


In the light of the above rule let's consider a very simple case of


dual PE attached site of L3VPN service. Two CEs would inject into=



their IBGP mesh routes to the remote destination: one marked as STALE<=
o:p>


and  one not marked at all. (Each CE is connected to different PE=
 and


each PE RT imports only a single route to a remote hub headquarter to<=
o:p>


support geographic load balancing).


 


Let me illustrate:


 


VPN Customer HUB


 


PE3      PE4 SP PE1    &n=
bsp; PE2 |        | |   &=
nbsp;    | CE1      CE2 |


| 1|        |10 |   =
     | R1 ------ R2 1


 


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


and R2-CE2 is 10.


 


Prefix X is advertised by remote hub in the given VPN such that PE1


vrf towards CE1 only has X via PE3 and PE2's vrf towards CE2 only has<=
o:p>


X via PE4.


 


Let's assume EBGP sessions PE3 to HUB went down, but ethernet link


is up, next hop is in the RIB while data plane is gone. Assume no=



data plane real validation too. /* That is why in my former message


I suggested that data plane validation would be necessary */.


 


R1 has X via PE1/S (stale) and X via PE2/A (active) - it understands


STALE so selects in his forwarding table path via CE2.

 


R2 has X via PE1/S (stale) and X via PE2/A (active) - it does not=



understand STALE, never was upgraded to support the forwarding rule


stated above in the draft and chooses X via CE1 (NH metric 2 vs 10).


 


R1--R2 produce data plane loop as long as STALE paths are present in


the system. Quite fun to troubleshoot too as the issue of PE3


injecting such STALE paths may be on the opposite site of the world.


 


The issue occurs when some routers within the customer site will be


able to recognize STALE transitive community and prefer non stale=



paths in their forwarding planes (or BGP planes for that matter)<=
/o:p>


while others will not as well as when both stale and non stale paths


will be present.


 


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


 


Question 2: How do you prevent forwarding loop in the case when


customer would have backup connectivity to his sites or connectivity


via different VPN provider yet routers in his site only partially=



understand the STALE community and only partially follow the


forwarding rules ?


 


In general as the rule is about mandating some particular order of


path forwarding selection what is the mechanism in distributed


systems like today's routing to be able to achieve any assurance that<=
o:p>


such rule is active and enforced across _all_ routers behind EBGP=



PE-CE L3VPN boundaries in customer sites ?


 


Best regards, R.


 


 


-------- Original Message -------- Subject: [Idr]


draft-uttaro-idr-bgp-persistence-00 Date: Sat, 22 Oct 2011 00:23:55


+0200 From: Robert Raszuk<=
robert@raszuk.net> Reply-To:


robert@raszuk.net To: idr@ietf.org List<idr@ietf.org>


 


Hi,


 


I have read the draft and have one question and one observation.<=
/o:p>


 


Question:


 


What is the point of defining DO_NOT_PERSIST community ? In other=



words why not having PERSIST community set would not mean the same as<=
o:p>


having path marked with DO_NOT_PERSIST.


 


Observation:


 


I found the below statement in section 4.2:


 


o  Forwarding must ensure that the Next Hop to a "stale"=
; route is


viable.


 


Of course I agree. But since we stating obvious in the forwarding=



section I think it would be good to explicitly also state this in=



the best path selection that next hop to STALE best path must be<=
/o:p>


valid.


 


However sessions especially those between loopbacks do not go down


for no reason. Most likely there is network problem which may have


caused those sessions to go down. It is therefor likely that LDP<=
/o:p>


session went also down between any of the LSRs in the data path and


that in spite of having the paths in BGP and next hops in IGP the LSP<=
o:p>


required for both quoted L2/L3VPN applications is broken. That may


particularly happen when network chooses to use independent control


mode for label allocation.


 


I would suggest to at least add the recommendation statement to the


document that during best path selection especially for stale paths


a validity of required forwarding paradigm to next hop of stale


paths should be verified.


 


For example using techniques as described in:


draft-ietf-idr-bgp-bestpath-selection-criteria


 


Best regards, R.


 


 


_______________________________________________ Idr mailing list<=
/o:p>


Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr<=
/a>


 


 


_______________________________________________ Idr mailing list<=
/o:p>


Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr<=
/a>


 


 




 


_______________________________________________


Idr mailing list


Idr@ietf.org


https://www.ietf=
.org/mailman/listinfo/idr




 


 
--_000_B17A6910EEDD1F45980687268941550FA21F96MISOUT7MSGUSR9IIT_-- From warren@kumari.net Tue Nov 1 10:24:55 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D42F21F0C6E for ; Tue, 1 Nov 2011 10:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hwa7R2pkGHth for ; Tue, 1 Nov 2011 10:24:55 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 79B121F0C44 for ; Tue, 1 Nov 2011 10:24:52 -0700 (PDT) Received: from [192.168.0.105] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 5340A1B40802; Tue, 1 Nov 2011 13:22:14 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <404F0C7A-5866-46AA-BD99-767D865E9FFE@juniper.net> Date: Tue, 1 Nov 2011 13:22:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8C4F7969-69AE-4507-8D54-9C0F6D2AC024@kumari.net> References: <4EAB1545.3000201@cisco.com> <404F0C7A-5866-46AA-BD99-767D865E9FFE@juniper.net> To: John Scudder X-Mailer: Apple Mail (2.1084) Cc: Keyur P Patel , "idr@ietf.org List" Subject: Re: [Idr] draft-keyur-idr-enhanced-gr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 17:24:55 -0000 On Oct 28, 2011, at 4:51 PM, John Scudder wrote: > Folks, >=20 > Please send comments to the list prior to the IDR meeting on November = 15. Support. W >=20 > Thanks, >=20 > --John >=20 > On Oct 28, 2011, at 4:49 PM, Enke Chen wrote: >=20 >> Hi, Sue and John: >>=20 >> We would like to request that the following draft be adopted as an = IDR WR document: >>=20 >> draft-keyur-idr-enhanced-gr-00.txt >>=20 >> It's presented at the last IETF. >>=20 >> Thanks. -- Enke >>=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 From robert@raszuk.net Tue Nov 1 11:35:14 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5C511E80F6 for ; Tue, 1 Nov 2011 11:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, GB_ABOUTYOU=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2LX+y-8ELXb for ; Tue, 1 Nov 2011 11:35:14 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id DC4EB11E80E6 for ; Tue, 1 Nov 2011 11:35:13 -0700 (PDT) Received: (qmail 27177 invoked by uid 399); 1 Nov 2011 18:35:13 -0000 Received: from unknown (HELO ?216.69.73.167?) (216.69.73.167) by mail37.opentransfer.com with SMTP; 1 Nov 2011 18:35:13 -0000 Message-ID: <4EB03BE0.8090504@raszuk.net> Date: Tue, 01 Nov 2011 19:35:12 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "UTTARO, JAMES" References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net> <4EA84254.9000400@raszuk.net> <4EA8A91C.4090305@cisco.com> <4EAA496C.9070605@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 18:35:14 -0000 Jim, > [Jim U>] One ex would be customers who create multiple VPNs over > different SPs.. A customer may want to take advantage of the > knowledge that a control plane failure has occurred and migrate the > traffic to the backup. This could be done at a path granularity by > use of the DO_NOT_PERSIST CV. . We as SPs want to provide our > customers with the tools needed to manage their VPNs and not > prescribe a one size fits all solution. I would recommend not to generalize "We as SPs" requirements as above. Some SPs may prefer to build their control plane in a robust and multi vendor way for any application they offer to customers in order to prevent from any control plane failures to impact the services. Other SPs may actually focus on delivering the actual services even during a transient control plane failures they may encounter. I do not think that DO_NOT_PERSIST community is the best way to indicate that peering network is multihomed and that it would prefer the normal BGP withdraw as opposed to receiving STALE routes from their service provider during said service provider encountering a control plane failure. It is clearly a very new requirement and justification for this proposal to develop a tool in order to communicate to your customers about your network's control plane failures even though data plane and services could continue to be active. With this in mind what is the mechanism build into this tool for your customers to indicate interest is receiving such information ? Best regards, R. From ju1738@att.com Tue Nov 1 12:26:16 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB481F0C5C for ; Tue, 1 Nov 2011 12:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.749 X-Spam-Level: X-Spam-Status: No, score=-105.749 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, GB_ABOUTYOU=0.5, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5zN2danc-xY for ; Tue, 1 Nov 2011 12:26:16 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 1556D1F0C58 for ; Tue, 1 Nov 2011 12:26:16 -0700 (PDT) X-Env-Sender: ju1738@att.com X-Msg-Ref: server-7.tower-120.messagelabs.com!1320175489!46955532!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26799 invoked from network); 1 Nov 2011 19:24:50 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-7.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Nov 2011 19:24:50 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pA1JPG3D017707; Tue, 1 Nov 2011 15:25:17 -0400 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pA1JPAOX017547 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 1 Nov 2011 15:25:10 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([169.254.1.231]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.01.0339.001; Tue, 1 Nov 2011 15:24:42 -0400 From: "UTTARO, JAMES" To: "'robert@raszuk.net'" Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-00 Thread-Index: AQHMkEAnLP0iAkRlVkChUYWtkZqOMZWKuQoAgAQhplCAAIdcwoABIPrwgAESmgCABpCw8IAAhjgA///InCA= Date: Tue, 1 Nov 2011 19:24:41 +0000 Message-ID: References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net> <4EA84254.9000400@raszuk.net> <4EA8A91C.4090305@cisco.com> <4EAA496C.9070605@cisco.com> <4EB03BE0.8090504@raszuk.net> In-Reply-To: <4EB03BE0.8090504@raszuk.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.84.170] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org List" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 19:26:16 -0000 Comments In-Line.. Thanks Jim Uttaro -----Original Message----- From: Robert Raszuk [mailto:robert@raszuk.net]=20 Sent: Tuesday, November 01, 2011 2:35 PM To: UTTARO, JAMES Cc: 'Enke Chen'; idr@ietf.org List Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 Jim, > [Jim U>] One ex would be customers who create multiple VPNs over > different SPs.. A customer may want to take advantage of the > knowledge that a control plane failure has occurred and migrate the > traffic to the backup. This could be done at a path granularity by > use of the DO_NOT_PERSIST CV. . We as SPs want to provide our > customers with the tools needed to manage their VPNs and not > prescribe a one size fits all solution. I would recommend not to generalize "We as SPs" requirements as above. [Jim U>] s/'We as SPs'/'As an SP'/ Some SPs may prefer to build their control plane in a robust and multi=20 vendor way for any application they offer to customers in order to=20 prevent from any control plane failures to impact the services. [Jim U>] That may or may not protect you as people architect/design/write c= ode. Other SPs may actually focus on delivering the actual services even=20 during a transient control plane failures they may encounter. I do not think that DO_NOT_PERSIST community is the best way to indicate=20 that peering network is multihomed and that it would prefer the normal=20 BGP withdraw as opposed to receiving STALE routes from their service=20 provider during said service provider encountering a control plane failure. [Jim U>] DO_NOT_PERSIST does not indicate that a network is multi-homed sim= ply allows for a speaker to be informed as to the viability of a control pl= ane. It does allow a peer/speaker/customer to make a decision as to whether= or not they want to continue using that network or to migrate away from it= in a graceful fashion It is clearly a very new requirement and justification for this proposal=20 to develop a tool in order to communicate to your customers about your=20 network's control plane failures even though data plane and services=20 could continue to be active. With this in mind what is the mechanism build into this tool for your=20 customers to indicate interest is receiving such information ? [Jim U>] ? I do not understand the question..=20 Best regards, R. From bruno.decraene@orange.com Wed Nov 2 01:36:40 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C932221F9FCE for ; Wed, 2 Nov 2011 01:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-1pyVZhzn0v for ; Wed, 2 Nov 2011 01:36:40 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 4473421F9FCC for ; Wed, 2 Nov 2011 01:36:40 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 47FF7FC4003; Wed, 2 Nov 2011 09:36:39 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 3BB6FFC4001; Wed, 2 Nov 2011 09:36:39 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Nov 2011 09:36:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Nov 2011 09:36:37 +0100 Message-ID: In-Reply-To: <056701cc97f7$416535d0$c42fa170$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] FW: draft-keyupate-idr-bgp-gr-notification-00.txt - Adoptionas working group draft Thread-Index: AcyV3dH5lc/eBPTQ+kql8WhTfRu0UwCFeBhwAFFSP6A= References: <056701cc97f7$416535d0$c42fa170$@com> From: To: , , X-OriginalArrivalTime: 02 Nov 2011 08:36:39.0270 (UTC) FILETIME=[8A33B860:01CC993A] Cc: idr@ietf.org Subject: Re: [Idr] FW: draft-keyupate-idr-bgp-gr-notification-00.txt - Adoptionas working group draft X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 08:36:40 -0000 > From: Susan Hares, Sent: Monday, October 31, 2011 7:02 PM >=20 > Folks:=20 > > The authors request the adoption of this draft.=20 > > draft-keyupate-idr-bgp-gr-notification-00.txt Support. > Comments should be sent to the mailing group by November 15th. > > Sue and John From bruno.decraene@orange.com Wed Nov 2 04:38:00 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 005F81F0CA2 for ; Wed, 2 Nov 2011 04:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNPcEPJO3sxr for ; Wed, 2 Nov 2011 04:37:59 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id DB2261F0C8E for ; Wed, 2 Nov 2011 04:37:58 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BFA3C958007; Wed, 2 Nov 2011 12:47:59 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id B8DAF958005; Wed, 2 Nov 2011 12:47:59 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Nov 2011 12:37:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Nov 2011 12:37:56 +0100 Message-ID: In-Reply-To: <4EA487E4.2040201@raszuk.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-00 Thread-Index: AcyRy1irIhHRBRl+R8yRIU+mzq3fewHgNfNg References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net> From: To: X-OriginalArrivalTime: 02 Nov 2011 11:37:57.0702 (UTC) FILETIME=[DE40B660:01CC9953] Cc: idr@ietf.org Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 11:38:00 -0000 Hi Robert, Sorry for the week delay. More inline. >From: Robert Raszuk >Sent: Sunday, October 23, 2011 11:32 PM > >Authors, > >Actually when discussing this draft a new concern surfaced which I would >like to get your answer on. > >The draft in section 4.2 says as one of the forwarding rules: > > o Forwarding to a "stale" route is only used if there are no other > paths available to that route. In other words an active path > always wins regardless of path selection. "Stale" state is always > considered to be less preferred when compared with an active path. > >In the light of the above rule let's consider a very simple case of dual >PE attached site of L3VPN service. Two CEs would inject into their IBGP >mesh routes to the remote destination: one marked as STALE and one not >marked at all. (Each CE is connected to different PE and each PE RT >imports only a single route to a remote hub headquarter to support >geographic load balancing). > >Let me illustrate: > > VPN Customer HUB > > PE3 PE4 > SP > PE1 PE2 > | | > | | > CE1 CE2 > | | > 1| |10 > | | > R1 ------ R2 > 1 > >CE1,CE2,R1,R2 are in IBGP mesh. IGP metric of CE1-R1 and R1-R2 are 1 and >R2-CE2 is 10. > >Prefix X is advertised by remote hub in the given VPN such that PE1 vrf >towards CE1 only has X via PE3 and PE2's vrf towards CE2 only has X via PE4. > >Let's assume EBGP sessions PE3 to HUB went down, but ethernet link is >up, next hop is in the RIB while data plane is gone. Assume no data >plane real validation too. /* That is why in my former message I >suggested that data plane validation would be necessary */. > >R1 has X via PE1/S (stale) and X via PE2/A (active) - it understands >STALE so selects in his forwarding table path via CE2. Nope. In your above case, I would expect the failure to be concealed within the SP AS: PE1 has X via PE1/S (stale) and X via PE2/A (active) - it understands STALE so selects in his forwarding table path via PE2. --> The customer does not see the "STALE" information. However, you bring very valid points, so let's continue (more comments below) >R2 has X via PE1/S (stale) and X via PE2/A (active) - it does not >understand STALE, never was upgraded to support the forwarding rule >stated above in the draft and chooses X via CE1 (NH metric 2 vs 10). > >R1--R2 produce data plane loop as long as STALE paths are present in the >system. Quite fun to troubleshoot too as the issue of PE3 injecting such >STALE paths may be on the opposite site of the world. > >The issue occurs when some routers within the customer site will be able >to recognize STALE transitive community and prefer non stale paths in >their forwarding planes (or BGP planes for that matter) while others >will not as well as when both stale and non stale paths will be present. > >Question 1: How do you prevent forwarding loop in such case ? You bring the issue of the incremental deployment of a feature which change the (BGP) routing decision. That's a valid point (not necessarily specific to the persistence draft). One answer is careful deployment of such features. However I the persistence draft could probably be improved to handles incremental deployment. This could be addressed in the next revision. A first tentative could be: - over an iBGP session, the router detecting the BGP session failure, flag the routes with a low (e.g. 0) LOCAL_PREF plus the STALE community. Within the AS, the STALE community does not influence routing decision but inform possible downstream BGP routers of the cause of the low local_pref. In particular that the LOCAL_PREF should probably not be further changed (some AS handles load balancing by rewriting the Local Pref on the ingress PE) - inform downstream AS of the STALE condition. First eBGP router could translate this community into a low local_pref. With the iBGP mesh, cf above. >Question 2: How do you prevent forwarding loop in the case when customer >would have backup connectivity to his sites or connectivity via >different VPN provider yet routers in his site only partially understand >the STALE community and only partially follow the forwarding rules ? Cf above. >In general as the rule is about mandating some particular order of path >forwarding selection what is the mechanism in distributed systems like >today's routing to be able to achieve any assurance that such rule is >active and enforced across _all_ routers behind EBGP PE-CE L3VPN >boundaries in customer sites ? Cf above. Best regards, Bruno >Best regards, >R. > > >-------- Original Message -------- >Subject: [Idr] draft-uttaro-idr-bgp-persistence-00 >Date: Sat, 22 Oct 2011 00:23:55 +0200 >From: Robert Raszuk >Reply-To: robert@raszuk.net >To: idr@ietf.org List > >Hi, > >I have read the draft and have one question and one observation. > >Question: > >What is the point of defining DO_NOT_PERSIST community ? In other words >why not having PERSIST community set would not mean the same as having >path marked with DO_NOT_PERSIST. > >Observation: > >I found the below statement in section 4.2: > > o Forwarding must ensure that the Next Hop to a "stale" route is > viable. > >Of course I agree. But since we stating obvious in the forwarding >section I think it would be good to explicitly also state this in the >best path selection that next hop to STALE best path must be valid. > >However sessions especially those between loopbacks do not go down for >no reason. Most likely there is network problem which may have caused >those sessions to go down. It is therefor likely that LDP session went >also down between any of the LSRs in the data path and that in spite of >having the paths in BGP and next hops in IGP the LSP required for both >quoted L2/L3VPN applications is broken. That may particularly happen >when network chooses to use independent control mode for label allocation. > >I would suggest to at least add the recommendation statement to the >document that during best path selection especially for stale paths a >validity of required forwarding paradigm to next hop of stale paths >should be verified. > >For example using techniques as described in: >draft-ietf-idr-bgp-bestpath-selection-criteria > >Best regards, >R. > > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr > > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From bruno.decraene@orange.com Wed Nov 2 06:34:48 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A2021F8C40 for ; Wed, 2 Nov 2011 06:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id teDZKkVd8sBi for ; Wed, 2 Nov 2011 06:34:48 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id EF30221F8C2D for ; Wed, 2 Nov 2011 06:34:47 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 23AC5FC4003; Wed, 2 Nov 2011 14:34:46 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 18CECFC4001; Wed, 2 Nov 2011 14:34:46 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Nov 2011 14:34:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Nov 2011 14:34:45 +0100 Message-ID: In-Reply-To: <4EA6540C.9090100@raszuk.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-00 Thread-Index: AcyS3YviefUBlZQcSB+uQGHjR+0EogGbp0rg References: <4EA1F0FB.3090100@raszuk.net> <4EA6540C.9090100@raszuk.net> From: To: X-OriginalArrivalTime: 02 Nov 2011 13:34:45.0930 (UTC) FILETIME=[2F7B70A0:01CC9964] Cc: idr@ietf.org, ju1738@att.com Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 13:34:49 -0000 Hi Robert, >From: Robert Raszuk, Sent: Tuesday, October 25, 2011 8:16 AM > >Hi Jim, > >> [Jim U>] Why do you believe that? BGP can >> and does fail independently of the underlying LDP session.. I do >> believe that viability of a data path between two endpoints should be >> taken into account when validating paths to NHs but that effort is >> clearly a much bigger effort.. This draft would take advantage of >> this mechanism but I am not looking to define that in this draft.. > >In my opinion there is a need to recognize the difference of possibly >locally using a stale path (and that is btw exactly what GR spec does .. >except here it would be GR per prefix with longer timer) versus keep >advertising paths which may be invalid. There may be a need to distinguish both. However, I wish you could explain why you see this need. BTW GR does both: locally keep a stale path _and_ implicitly keep advertising a path which may be invalid.=20 >> I would suggest to at least add the recommendation statement to the >> document that during best path selection especially for stale paths >> a validity of required forwarding paradigm to next hop of stale >> paths should be verified. [Jim U>] Why would this not be something >> that needs to be done as a general rule for paths.. I mean the >> underlying LSP could fail independently of BGP.. If this needs to be >> done in should be done as a general rule... > >Respectfully disagree. > >I am sure you very well know how many customers are relaying on using >BGP keepalives to determine PE-CE link up and PE-CE reachability. Recall >how many times SP customers including your own customers were asking to >reduce holdtime on their ebgp session to 3/9 ... those customers just do >not have a better way to determine VPN site reachability. Regarding the activation of persistence over an eBGP PE-CE session, I agree both with you and Jim that you would need to evaluate how much the forwarding will share fate with the BGP session. And if there is a doubt, you would need to check forwarding status (e.g. BFD if link level info is not reliable). Note however, that this is not new. GR has the same issue (e.g. if on the CE the forwarding share fate with the control plane, you should not enable BG GR). Note also that even if persistence take the wrong decision (i.e. advertise the route while the forwarding is down) if the site is not dual homed, the issue is limited as traffic is dropped in all cases. And if the site is dual homed, persistence will favor the backup link. Hence the status of the forwarding is less important that for GR, which do use the link/BGP session with an uncertain status. >Of course such reduction of keepalives is a bad idea (even if their >processing is offloaded or prioritized on main RP) so BFD was invented >to address this issue. And either BFD if present or EBGP session up >state was _the_only_ probe to determine if CE over frame relay PVC or >multiaccess media is live. That is the key difference. > >So when you drop session you remove prefixes advertised from the site >and backup can be activated. Now you are proposing to keep advertising >them as STALE which really means MAYBE_REACHABLE. I am not sure why >validation of next hop reachability by BFD or even OBJECT_TRACKING or >SCRIPT would be at all difficult. > >Anyway I think this proposal as pointed out in the other email has much >bigger deployment issue so I think there is not much point on this >validation debate at this point before the loop problem is solved due to >inconsistent forwarding plane decisions. > >Best regards, >R. >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From robert@raszuk.net Wed Nov 2 06:39:18 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F6311E809B for ; Wed, 2 Nov 2011 06:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mw7b1T7Krqw for ; Wed, 2 Nov 2011 06:39:17 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id 38A7A11E8090 for ; Wed, 2 Nov 2011 06:39:17 -0700 (PDT) Received: (qmail 16736 invoked by uid 399); 2 Nov 2011 13:39:16 -0000 Received: from unknown (HELO ?192.168.1.52?) (83.31.220.67) by mail37.opentransfer.com with SMTP; 2 Nov 2011 13:39:16 -0000 Message-ID: <4EB147F6.1090906@raszuk.net> Date: Wed, 02 Nov 2011 14:39:02 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: bruno.decraene@orange.com References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 13:39:18 -0000 Hi Bruno, > Nope. In your above case, I would expect the failure to be concealed > within the SP AS: > > PE1 has X via PE1/S (stale) and X via PE2/A (active) - it understands > STALE so selects in his forwarding table path via PE2. > > --> The customer does not see the "STALE" information. Nope - it sure does. As I have obviously foreseen you are going to say so I specifically pointed out that there is no symmetry on the PEs due to the specific RT configuration. See below quote: "Prefix X is advertised by remote hub in the given VPN such that PE1 vrf towards CE1 only has X via PE3 and PE2's vrf towards CE2 only has X via PE4." > You bring the issue of the incremental deployment of a feature which > change the (BGP) routing decision. That's a valid point (not necessarily > specific to the persistence draft). I think any draft modifying routing decision should discuss such issues. > One answer is careful deployment of such features. I am afraid this is very difficult to achieve across EBGP boundaries. If you would just limit STALE to IBGP I would perhaps have a bit lighter objection :) > However I the persistence draft could probably be improved to handles > incremental deployment. This could be addressed in the next revision. > A first tentative could be: > - over an iBGP session, the router detecting the BGP session failure, > flag the routes with a low (e.g. 0) LOCAL_PREF plus the STALE community. > Within the AS, the STALE community does not influence routing decision > but inform possible downstream BGP routers of the cause of the low > local_pref. In particular that the LOCAL_PREF should probably not be > further changed (some AS handles load balancing by rewriting the Local > Pref on the ingress PE) > - inform downstream AS of the STALE condition. First eBGP router could > translate this community into a low local_pref. With the iBGP mesh, cf > above. Translating STALE to Local Pref over EBGP and not using STALE for local decision makes the proposal much less dangerous indeed. Is any action associated with STALE going to be disabled by default in all BGP implementations ? If yes I would see it acceptable - provided the above changes are introduced. However if any implementation is going to enable auto translation of STALE to local pref = 0 across EBGP boundary, or make best path decision based on STALE presence - we have the same problem as soon as any two routers are not upgraded in the same time to the same vendor's code version. -- Regardless how novel and appealing is the idea of telling your customer that you can possibly forward, but your control plane is undergoing recovery - I still think that churn introduced by this sort of signalling on a per path basis is a pretty bad idea. If anything I would rather see this in the BGP Operational Message not in the actual routing UPDATE messages. Cheers, R. From bruno.decraene@orange.com Wed Nov 2 06:47:45 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3BE1F0C34 for ; Wed, 2 Nov 2011 06:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8Cd+WEa2b4u for ; Wed, 2 Nov 2011 06:47:44 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 4426021F8E8E for ; Wed, 2 Nov 2011 06:47:44 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 94850958005; Wed, 2 Nov 2011 14:57:45 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 6DAAE858001; Wed, 2 Nov 2011 14:57:45 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Nov 2011 14:47:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Nov 2011 14:47:42 +0100 Message-ID: In-Reply-To: <4EA84254.9000400@raszuk.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-00 Thread-Index: AcyUBCe+VvraTrEdQiKBo9MV3jvoXQFSMVqA References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net> <4EA84254.9000400@raszuk.net> From: To: , X-OriginalArrivalTime: 02 Nov 2011 13:47:43.0393 (UTC) FILETIME=[FEE2E110:01CC9965] Cc: idr@ietf.org Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 13:47:45 -0000 Robert, >Jim, > >When one during design phase of a routing protocol or routing protocol >extension or modification to it already realizes that enabling such >feature may cause real network issue if not done carefully - that should >trigger the alarm to rethink the solution and explore alternative >approaches to the problem space. > >We as operators have already hard time to relate enabling a feature >within our intradomain boundaries to make sure such rollout is network >wide. Here you are asking for the same level of awareness across ebgp >boundaries. This is practically unrealistic IMHO. > >Back to the proposal ... I think that if anything needs to be done is to >employ per prefix GR with longer and locally configurable timer. That >would address information persistence across direct IBGP sessions. > >On the RRs use case of this draft we may perhaps agree to disagree, but >I do not see large enough probability of correctly engineered RR plane >to experience simultaneous multiple ibgp session drops. If that happens >the RR placement, platforms or deployment model should be re-engineered. The low chance / probability of the failure of both RR planes is indeed a good point. I can also agree that this is expected to be low. I disagree that it never happens. E.g. with current BGP error handling, the same BGP attribute in "error" would cause both iBGP plane to go down. Hopefully work is being done to improve this. But I would not bet that this will cover all future cases. In such catastrophic cases, some routing is better than no routing. On a side note, considering that the RR and hence their failure are independent and therefore will quite never fail at the same time, is questionable. To start with, they process they mostly process the same input (BGP updates) and are part of the same network.=20 >Summary .. I do not think that IDR WG should adopt this document. Just >adding a warning to the deployment section is not sufficient. > >Best regards, >R. > > >> Robert, >> >> The introduction of this technology needs to be carefully evaluated >> when being deployed into the network. Your example clearly calls out >> how a series of independent design can culminate in incorrect >> behavior. Certainly the deployment of persistence on a router that >> has interaction with a router that does not needs to be clearly >> understood by the network designer. The goal of this draft is to >> provide a fairly sophisticated tool that will protect the majority of >> customers in the event of a catastrophic failure.. The premise being >> the perfect is not the enemy of the good.. I will add text in the >> deployment considerations section to better articulate that.. >> >> Thanks, Jim Uttaro >> >> -----Original Message----- From: idr-bounces@ietf.org >> [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: >> Sunday, October 23, 2011 5:32 PM To: idr@ietf.org List Subject: [Idr] >> draft-uttaro-idr-bgp-persistence-00 >> >> Authors, >> >> Actually when discussing this draft a new concern surfaced which I >> would like to get your answer on. >> >> The draft in section 4.2 says as one of the forwarding rules: >> >> o Forwarding to a "stale" route is only used if there are no other >> paths available to that route. In other words an active path always >> wins regardless of path selection. "Stale" state is always >> considered to be less preferred when compared with an active path. >> >> In the light of the above rule let's consider a very simple case of >> dual PE attached site of L3VPN service. Two CEs would inject into >> their IBGP mesh routes to the remote destination: one marked as STALE >> and one not marked at all. (Each CE is connected to different PE and >> each PE RT imports only a single route to a remote hub headquarter to >> support geographic load balancing). >> >> Let me illustrate: >> >> VPN Customer HUB >> >> PE3 PE4 SP PE1 PE2 | | | | CE1 CE2 | >> | 1| |10 | | R1 ------ R2 1 >> >> CE1,CE2,R1,R2 are in IBGP mesh. IGP metric of CE1-R1 and R1-R2 are 1 >> and R2-CE2 is 10. >> >> Prefix X is advertised by remote hub in the given VPN such that PE1 >> vrf towards CE1 only has X via PE3 and PE2's vrf towards CE2 only has >> X via PE4. >> >> Let's assume EBGP sessions PE3 to HUB went down, but ethernet link >> is up, next hop is in the RIB while data plane is gone. Assume no >> data plane real validation too. /* That is why in my former message >> I suggested that data plane validation would be necessary */. >> >> R1 has X via PE1/S (stale) and X via PE2/A (active) - it understands >> STALE so selects in his forwarding table path via CE2. >> >> R2 has X via PE1/S (stale) and X via PE2/A (active) - it does not >> understand STALE, never was upgraded to support the forwarding rule >> stated above in the draft and chooses X via CE1 (NH metric 2 vs 10). >> >> R1--R2 produce data plane loop as long as STALE paths are present in >> the system. Quite fun to troubleshoot too as the issue of PE3 >> injecting such STALE paths may be on the opposite site of the world. >> >> The issue occurs when some routers within the customer site will be >> able to recognize STALE transitive community and prefer non stale >> paths in their forwarding planes (or BGP planes for that matter) >> while others will not as well as when both stale and non stale paths >> will be present. >> >> Question 1: How do you prevent forwarding loop in such case ? >> >> Question 2: How do you prevent forwarding loop in the case when >> customer would have backup connectivity to his sites or connectivity >> via different VPN provider yet routers in his site only partially >> understand the STALE community and only partially follow the >> forwarding rules ? >> >> In general as the rule is about mandating some particular order of >> path forwarding selection what is the mechanism in distributed >> systems like today's routing to be able to achieve any assurance that >> such rule is active and enforced across _all_ routers behind EBGP >> PE-CE L3VPN boundaries in customer sites ? >> >> Best regards, R. >> >> >> -------- Original Message -------- Subject: [Idr] >> draft-uttaro-idr-bgp-persistence-00 Date: Sat, 22 Oct 2011 00:23:55 >> +0200 From: Robert Raszuk Reply-To: >> robert@raszuk.net To: idr@ietf.org List >> >> Hi, >> >> I have read the draft and have one question and one observation. >> >> Question: >> >> What is the point of defining DO_NOT_PERSIST community ? In other >> words why not having PERSIST community set would not mean the same as >> having path marked with DO_NOT_PERSIST. >> >> Observation: >> >> I found the below statement in section 4.2: >> >> o Forwarding must ensure that the Next Hop to a "stale" route is >> viable. >> >> Of course I agree. But since we stating obvious in the forwarding >> section I think it would be good to explicitly also state this in >> the best path selection that next hop to STALE best path must be >> valid. >> >> However sessions especially those between loopbacks do not go down >> for no reason. Most likely there is network problem which may have >> caused those sessions to go down. It is therefor likely that LDP >> session went also down between any of the LSRs in the data path and >> that in spite of having the paths in BGP and next hops in IGP the LSP >> required for both quoted L2/L3VPN applications is broken. That may >> particularly happen when network chooses to use independent control >> mode for label allocation. >> >> I would suggest to at least add the recommendation statement to the >> document that during best path selection especially for stale paths >> a validity of required forwarding paradigm to next hop of stale >> paths should be verified. >> >> For example using techniques as described in: >> draft-ietf-idr-bgp-bestpath-selection-criteria >> >> Best regards, R. >> >> >> _______________________________________________ Idr mailing list >> Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr >> >> >> _______________________________________________ Idr mailing list >> Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr >> >> > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From robert@raszuk.net Wed Nov 2 06:55:57 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C30421F8BEF for ; Wed, 2 Nov 2011 06:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7xZon27cDBL for ; Wed, 2 Nov 2011 06:55:56 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id 6B07021F8BE8 for ; Wed, 2 Nov 2011 06:55:56 -0700 (PDT) Received: (qmail 23767 invoked by uid 399); 2 Nov 2011 13:55:55 -0000 Received: from unknown (HELO ?192.168.1.52?) (83.31.220.67) by mail37.opentransfer.com with SMTP; 2 Nov 2011 13:55:55 -0000 Message-ID: <4EB14BDD.7040802@raszuk.net> Date: Wed, 02 Nov 2011 14:55:41 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: bruno.decraene@orange.com References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net> <4EA84254.9000400@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org, ju1738@att.com Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 13:55:57 -0000 Bruno, > The low chance / probability of the failure of both RR planes is indeed > a good point. I can also agree that this is expected to be low. I > disagree that it never happens. E.g. with current BGP error handling, > the same BGP attribute in "error" would cause both iBGP plane to go > down. Hopefully work is being done to improve this. But I would not bet > that this will cover all future cases. If trigger is due to malformed update why are we so concerned about RRs? Wouldn't equally susceptible be also PEs/ASBRs ? And the cure that those is GR, not persistence ;). > In such catastrophic cases, some routing is better than no routing. I don't know about that. > On a side note, considering that the RR and hence their failure are > independent and therefore will quite never fail at the same time, is > questionable. To start with, they process they mostly process the same > input (BGP updates) and are part of the same network. I don't think I used the term "never". But with dual or triple vendor control plane the probability of RR network wide outage drops significantly lower. Cheers, R. From bruno.decraene@orange.com Wed Nov 2 07:15:31 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5B611E80CB for ; Wed, 2 Nov 2011 07:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVuNLZ9wWCGx for ; Wed, 2 Nov 2011 07:15:30 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC1011E808A for ; Wed, 2 Nov 2011 07:15:29 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EEA9BB58002; Wed, 2 Nov 2011 15:25:30 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id E7D13B58001; Wed, 2 Nov 2011 15:25:30 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Nov 2011 15:15:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Nov 2011 15:15:27 +0100 Message-ID: In-Reply-To: <4EA8A91C.4090305@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-00 Thread-Index: AcyUQUb+J/mObyQeSIyTG6czgqxViAFC9aXg References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net><4EA84254.9000400@raszuk.net> <4EA8A91C.4090305@cisco.com> From: To: X-OriginalArrivalTime: 02 Nov 2011 14:15:28.0930 (UTC) FILETIME=[DF9FA820:01CC9969] Cc: idr@ietf.org Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 14:15:31 -0000 Hi Enke, >From: Enke Chen; Sent: Thursday, October 27, 2011 2:43 AM > >Hi, folks: > >I have a hard time in understanding what new problems (beyond the GR) >the draft try to solve :-( That's a good comment. Do you think the draft should put both GR and persistence into perspective? (e.g. either in the introduction or in appendix) >If the concern is about the simultaneous RR failure as shown in the >examples in Sect. 6 Application, that can be addressed easily using GR. >As the RRs are not in the forwarding path, it means that the forwarding >is not impacted (thus is preserved) during the restart of a RR. The >Forwarding State bit (F) in the GR capability should always be set by >the RR when it is not in the forwarding path. GR has limitations: limited duration, does not handle consecutive session restarts, (currently) does not handle BGP failures, does not advertise that the STALE path may be less trusted. >Also in the case of simultaneous RR failure, I do not see why one would >want to retain some routes, but not others, using the communities >specified in the draft. As the RRs are not in the forwarding path, >wouldn't be better to retain all the routes on a PE/client? I find interesting that you considered that all routes would be kept STALE for a long time. I was rather anticipating that some people would be uncomfortable with this, especially in the VPN cases as correct and up to date routing information are required to ensure isolation between VPNs. (cf security section of the persistence draft). Regarding your point, some route could be fairly static and hence kept STALE for a long time. Other routes may be more dynamic and more problematic to keep STALE for a long time. Hence the ability for a different response. Also, some route may be more critical than others. >As you might be aware, efforts have been underway to address issues with >GR found during implementation and deployment. They include the spec >respin, notification handling, and implementations. If there are issues >in the GR area that are not adequately addressed, I suggest that we try >to address them in the GR respin if possible, instead of creating >another variation unnecessarily. Indeed, possibly the persistence requirements could be inserted in the GR draft. But how much are you / IDR WG ready to change that much the GR procedures? That would basically force all GR implementations to implement the persistence behavior. Besides, IMHO, GR and persistence make different assumptions and hence are rather different: - GR assumes that the forwarding is preserved during the BGP session restart and hence decides to not advertise this event in the network. For such assumption, you need to believe pretty strongly that the forwarding is indeed preserved. IMHO this calls for a short timer duration and quick fall back to session failure if you suspect this may not be the case (e.g. in case of consecutive restart of the BGP session, GR is aborted). - "persistence" considers that in case of issues, some stale information is better than no information, but worst than correct information. The downside is BGP churn to advertise the event. The good side is that this is a safer assumption hence more likely to be valid over time or events. Regards, Bruno > >Thanks. -- Enke > > >On 10/26/11 10:24 AM, Robert Raszuk wrote: >> Jim, >> >> When one during design phase of a routing protocol or routing protocol >> extension or modification to it already realizes that enabling such >> feature may cause real network issue if not done carefully - that >> should trigger the alarm to rethink the solution and explore >> alternative approaches to the problem space. >> >> We as operators have already hard time to relate enabling a feature >> within our intradomain boundaries to make sure such rollout is network >> wide. Here you are asking for the same level of awareness across ebgp >> boundaries. This is practically unrealistic IMHO. >> >> Back to the proposal ... I think that if anything needs to be done is >> to employ per prefix GR with longer and locally configurable timer. >> That would address information persistence across direct IBGP sessions. >> >> On the RRs use case of this draft we may perhaps agree to disagree, >> but I do not see large enough probability of correctly engineered RR >> plane to experience simultaneous multiple ibgp session drops. If that >> happens the RR placement, platforms or deployment model should be >> re-engineered. >> >> Summary .. I do not think that IDR WG should adopt this document. Just >> adding a warning to the deployment section is not sufficient. >> >> Best regards, >> R. >> >> >>> Robert, >>> >>> The introduction of this technology needs to be carefully evaluated >>> when being deployed into the network. Your example clearly calls out >>> how a series of independent design can culminate in incorrect >>> behavior. Certainly the deployment of persistence on a router that >>> has interaction with a router that does not needs to be clearly >>> understood by the network designer. The goal of this draft is to >>> provide a fairly sophisticated tool that will protect the majority of >>> customers in the event of a catastrophic failure.. The premise being >>> the perfect is not the enemy of the good.. I will add text in the >>> deployment considerations section to better articulate that.. >>> >>> Thanks, Jim Uttaro >>> >>> -----Original Message----- From: idr-bounces@ietf.org >>> [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: >>> Sunday, October 23, 2011 5:32 PM To: idr@ietf.org List Subject: [Idr] >>> draft-uttaro-idr-bgp-persistence-00 >>> >>> Authors, >>> >>> Actually when discussing this draft a new concern surfaced which I >>> would like to get your answer on. >>> >>> The draft in section 4.2 says as one of the forwarding rules: >>> >>> o Forwarding to a "stale" route is only used if there are no other >>> paths available to that route. In other words an active path always >>> wins regardless of path selection. "Stale" state is always >>> considered to be less preferred when compared with an active path. >>> >>> In the light of the above rule let's consider a very simple case of >>> dual PE attached site of L3VPN service. Two CEs would inject into >>> their IBGP mesh routes to the remote destination: one marked as STALE >>> and one not marked at all. (Each CE is connected to different PE and >>> each PE RT imports only a single route to a remote hub headquarter to >>> support geographic load balancing). >>> >>> Let me illustrate: >>> >>> VPN Customer HUB >>> >>> PE3 PE4 SP PE1 PE2 | | | | CE1 CE2 | >>> | 1| |10 | | R1 ------ R2 1 >>> >>> CE1,CE2,R1,R2 are in IBGP mesh. IGP metric of CE1-R1 and R1-R2 are 1 >>> and R2-CE2 is 10. >>> >>> Prefix X is advertised by remote hub in the given VPN such that PE1 >>> vrf towards CE1 only has X via PE3 and PE2's vrf towards CE2 only has >>> X via PE4. >>> >>> Let's assume EBGP sessions PE3 to HUB went down, but ethernet link >>> is up, next hop is in the RIB while data plane is gone. Assume no >>> data plane real validation too. /* That is why in my former message >>> I suggested that data plane validation would be necessary */. >>> >>> R1 has X via PE1/S (stale) and X via PE2/A (active) - it understands >>> STALE so selects in his forwarding table path via CE2. >>> >>> R2 has X via PE1/S (stale) and X via PE2/A (active) - it does not >>> understand STALE, never was upgraded to support the forwarding rule >>> stated above in the draft and chooses X via CE1 (NH metric 2 vs 10). >>> >>> R1--R2 produce data plane loop as long as STALE paths are present in >>> the system. Quite fun to troubleshoot too as the issue of PE3 >>> injecting such STALE paths may be on the opposite site of the world. >>> >>> The issue occurs when some routers within the customer site will be >>> able to recognize STALE transitive community and prefer non stale >>> paths in their forwarding planes (or BGP planes for that matter) >>> while others will not as well as when both stale and non stale paths >>> will be present. >>> >>> Question 1: How do you prevent forwarding loop in such case ? >>> >>> Question 2: How do you prevent forwarding loop in the case when >>> customer would have backup connectivity to his sites or connectivity >>> via different VPN provider yet routers in his site only partially >>> understand the STALE community and only partially follow the >>> forwarding rules ? >>> >>> In general as the rule is about mandating some particular order of >>> path forwarding selection what is the mechanism in distributed >>> systems like today's routing to be able to achieve any assurance that >>> such rule is active and enforced across _all_ routers behind EBGP >>> PE-CE L3VPN boundaries in customer sites ? >>> >>> Best regards, R. >>> >>> >>> -------- Original Message -------- Subject: [Idr] >>> draft-uttaro-idr-bgp-persistence-00 Date: Sat, 22 Oct 2011 00:23:55 >>> +0200 From: Robert Raszuk Reply-To: >>> robert@raszuk.net To: idr@ietf.org List >>> >>> Hi, >>> >>> I have read the draft and have one question and one observation. >>> >>> Question: >>> >>> What is the point of defining DO_NOT_PERSIST community ? In other >>> words why not having PERSIST community set would not mean the same as >>> having path marked with DO_NOT_PERSIST. >>> >>> Observation: >>> >>> I found the below statement in section 4.2: >>> >>> o Forwarding must ensure that the Next Hop to a "stale" route is >>> viable. >>> >>> Of course I agree. But since we stating obvious in the forwarding >>> section I think it would be good to explicitly also state this in >>> the best path selection that next hop to STALE best path must be >>> valid. >>> >>> However sessions especially those between loopbacks do not go down >>> for no reason. Most likely there is network problem which may have >>> caused those sessions to go down. It is therefor likely that LDP >>> session went also down between any of the LSRs in the data path and >>> that in spite of having the paths in BGP and next hops in IGP the LSP >>> required for both quoted L2/L3VPN applications is broken. That may >>> particularly happen when network chooses to use independent control >>> mode for label allocation. >>> >>> I would suggest to at least add the recommendation statement to the >>> document that during best path selection especially for stale paths >>> a validity of required forwarding paradigm to next hop of stale >>> paths should be verified. >>> >>> For example using techniques as described in: >>> draft-ietf-idr-bgp-bestpath-selection-criteria >>> >>> Best regards, R. >>> >>> >>> _______________________________________________ Idr mailing list >>> Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr >>> >>> >>> _______________________________________________ Idr mailing list >>> Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr >>> >>> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From bruno.decraene@orange.com Wed Nov 2 07:45:08 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F3A11E80B6 for ; Wed, 2 Nov 2011 07:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0iqCOuiVHkP for ; Wed, 2 Nov 2011 07:44:59 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC3321F8E21 for ; Wed, 2 Nov 2011 07:44:58 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BB1B79B0002; Wed, 2 Nov 2011 15:45:59 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id A04098F0001; Wed, 2 Nov 2011 15:45:59 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Nov 2011 15:44:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC996D.FD290DEE" Date: Wed, 2 Nov 2011 15:44:56 +0100 Message-ID: In-Reply-To: <4EAA496C.9070605@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-00 Thread-Index: AcyVOX60v/Fmg6/PRreOWt6b9nPXSAEFQVbg References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net><4EA84254.9000400@raszuk.net> <4EA8A91C.4090305@cisco.com> <4EAA496C.9070605@cisco.com> From: To: X-OriginalArrivalTime: 02 Nov 2011 14:44:57.0519 (UTC) FILETIME=[FDC8EBF0:01CC996D] Cc: idr@ietf.org Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 14:45:08 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC996D.FD290DEE Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Enke, =20 Please find some comments inlined [BD] =20 From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Enke Chen Sent: Friday, October 28, 2011 8:19 AM To: UTTARO, JAMES Cc: idr@ietf.org List; robert@raszuk.net Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 =20 Jim, My comments are inlined. On 10/27/11 1:17 PM, UTTARO, JAMES wrote:=20 Enke, =20 GR is a solution that is essentially local in scope it does not have the ability to inform downstream speakers of the viability of routing state from the point of possible control plane failure. OTOH Persistence does propagate the condition of state. This provides distinct advantages in terms of customers awareness of the SPs control plane. One could imagine a customer receiving a STALE path and responding by selecting a backup. Some of the extensions to this draft that I have considered in colouring of STALE to inform if the condition arises from a local ( PE ) or internal iBGP ( RR ) failures..=20 =20 GR makes no distinction from STALE state and ACTIVE state.. This can lead to the STALE path still being preferred throughout the topology. IMO this is incorrect behavior regardless of the comparison.=20 =20 PERSISTENCE allows for a customer to indicate which paths should be candidates. Customers may want to immediately failover to the backup for some paths and not for others. GR is not capable of doing this it is all or nothing. The granularity is not sufficient. It needs to be at the path level. There may even be a case for having even more granularity i.e a per path timer.. GR is not capable of being extended for either of these cases. I am not sure how this path level persistence would work operationally. Without the detailed information of a provider's network, how would a customer know what kind of failures and recovery that they might experience? Consider the example of the simultaneous RR failures in the draft, why wouldn't any customer not to want to protect against such failures? The end result could be that the PERSISTENCE flag is always set, thus losing its significance. Regarding the use of the STALE state vs ACTIVE state, clearly there is a tradeoff. [BD] clearly. Cf my previous email. =20 GR uses the stale routes in order to avoid forwarding churns, which has been a critical requirement for a long time. If there is a real need for favoring a ACTIVE one over a STALE one in GR, it can be done by a simple knob. [BD] That "simple knob" would contradict the GR spec "The router MUST NOT differentiate between stale and other routing information during forwarding." =20 As you know, BGP is full of knobs that adjust behaviors for different needs :-) [BD] sure. But I fail to see why a set of knobs independently defined by each implementation would be better than a draft describing the expected behavior. =20 =20 GR does not provide protection through successive restarts of the session. I believe that if this occurs the state will be invalidated. So for a session that is bouncing due to overload condition GR will not provide the required protection This can be addressed by a simple knob to set the min stale timer for GR. [BD] I'm not sure to understand how changing the min stale timer would address this. Again, this "simple knob" would contradict the GR spec "To deal with possible consecutive restarts, a route (from the peer) previously marked as stale MUST be deleted." =20 =20 GR does not employ a make before break strategy. All state is invalidated first then the newly learned state is processed. This leads to routing churn especially if the majority of the state is the same which I am pretty sure is the case Such behavior would be an implementation bug that needs to be fixed. But it is not an issue with the protocol itself. This is what we have in 4.2. Procedures for the Receiving Speaker, RFC 4724: --- The Receiving Speaker MUST replace the stale routes by the routing updates received from the peer. Once the End-of-RIB marker for an address family is received from the peer, it MUST immediately remove any routes from the peer that are still marked as stale for that address family. --- There are several possibilities for the premature purge of the stale routes. For example, the "Forwarding state" flag was somehow not set after the session was re-established, or the the EOR was sent prematurely. Further investigation will be needed in order to identify any possible implementation or config issues involved in your setup. =20 =20 GR invalidates state due to the case of protocol error i.e A malformed update will invalidate all of the state. This is not the desired behavior. It has been addressed by the following extension: http://datatracker.ietf.org/doc/draft-keyupate-idr-bgp-gr-notification/ =20 [BD] I would rather have said that this should be addressed by draft-ietf-idr-optional-transitive-04. (as in case of a malformed update, draft-keyupate-idr-bgp-gr-notification, would mostly GR restart the BGP session again and again indefinitely). However, as hard as we try, I would not bet that draft-ietf-idr-optional-transitive will cover all possible future cases. This is mostly a (good IMHO) reaction to past issue, rather than a solution to all future issues BGP could have to face. OTOH, persistence could be the safety net to address the unexpected issues. =20 =20 GR is not specific as to which events invoke it or not. From my read on the draft it is not clear if holdtime expiration invokes GR or not.. The draft is unclear. I think that it is covered by the above extension. If not, it should be clarified. [BD] Indeed. I think this should be clarify in the GR spec. Could you please clarify this in draft-chen-idr-rfc4724bis-00.txt? =20 It is not clear to me how RRs and PEs differ in using GR.=20 I think that there is a main difference when a RR is not in the forwarding path. In that case, the RR should always set the F bit in the GR Capability so that its clients will continue forwarding after they lose the sessions with RR. It is a deployment issue, though. =20 =20 The time that state can persist is limit to about 1 hour max.=20 I think that you are talking about the "Restart time" field which has 12 bits and amount to about 68 minutes. The "Restart time" is for the session re-establishment. It does not impact the duration for holding stale routes after the session is re-established. If the session does not get re-established in 68 minutes, the stale routes would be purged. That is a long time, isn't it? However, if one really wants to extend the session re-establishment time and continue to hold stale routes, it can be done by a simple knob. [BD] It's advertised in the GR capability and bounded by the 12 bits fields. Eventually, you could have local knob to override every GR behavior, but I would not call this GR anymore. =20 =20 GR does detail the behavior where convergence is not achieved between restarts.. Similar to above..=20 The min stale timer knob can cover it (see above). But do you meant "does not"? We can certainly clarify in 4724bis if that is the case. =20 =20 I do not believe that the current GR paradigm can be extended to cover the majority of the cases above. Except for the path level persistence you mentioned, I believe the GR will be able to address all other persistence requirements you listed, with some simple knobs and some implementation enhancements.=20 [BD] What about calling "persistence" this set of "simple knobs and implementation enhancements"? Regards, Bruno =20 Thanks, Jim Uttaro Thanks. -- Enke =20 =20 -----Original Message----- From: Enke Chen [mailto:enkechen@cisco.com]=20 Sent: Wednesday, October 26, 2011 8:43 PM To: UTTARO, JAMES Cc: robert@raszuk.net; idr@ietf.org List; Enke Chen Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 =20 Hi, folks: =20 I have a hard time in understanding what new problems (beyond the GR)=20 the draft try to solve :-( =20 If the concern is about the simultaneous RR failure as shown in the=20 examples in Sect. 6 Application, that can be addressed easily using GR. As the RRs are not in the forwarding path, it means that the forwarding=20 is not impacted (thus is preserved) during the restart of a RR. The=20 Forwarding State bit (F) in the GR capability should always be set by=20 the RR when it is not in the forwarding path. =20 Also in the case of simultaneous RR failure, I do not see why one would=20 want to retain some routes, but not others, using the communities=20 specified in the draft. As the RRs are not in the forwarding path,=20 wouldn't be better to retain all the routes on a PE/client? =20 As you might be aware, efforts have been underway to address issues with GR found during implementation and deployment. They include the spec=20 respin, notification handling, and implementations. If there are issues in the GR area that are not adequately addressed, I suggest that we try to address them in the GR respin if possible, instead of creating=20 another variation unnecessarily. =20 Thanks. -- Enke =20 =20 On 10/26/11 10:24 AM, Robert Raszuk wrote: Jim, =20 When one during design phase of a routing protocol or routing protocol=20 extension or modification to it already realizes that enabling such=20 feature may cause real network issue if not done carefully - that=20 should trigger the alarm to rethink the solution and explore=20 alternative approaches to the problem space. =20 We as operators have already hard time to relate enabling a feature=20 within our intradomain boundaries to make sure such rollout is network=20 wide. Here you are asking for the same level of awareness across ebgp=20 boundaries. This is practically unrealistic IMHO. =20 Back to the proposal ... I think that if anything needs to be done is=20 to employ per prefix GR with longer and locally configurable timer.=20 That would address information persistence across direct IBGP sessions. =20 On the RRs use case of this draft we may perhaps agree to disagree,=20 but I do not see large enough probability of correctly engineered RR=20 plane to experience simultaneous multiple ibgp session drops. If that=20 happens the RR placement, platforms or deployment model should be=20 re-engineered. =20 Summary .. I do not think that IDR WG should adopt this document. Just=20 adding a warning to the deployment section is not sufficient. =20 Best regards, R. =20 =20 Robert, =20 The introduction of this technology needs to be carefully evaluated when being deployed into the network. Your example clearly calls out how a series of independent design can culminate in incorrect behavior. Certainly the deployment of persistence on a router that has interaction with a router that does not needs to be clearly understood by the network designer. The goal of this draft is to provide a fairly sophisticated tool that will protect the majority of customers in the event of a catastrophic failure.. The premise being the perfect is not the enemy of the good.. I will add text in the deployment considerations section to better articulate that.. =20 Thanks, Jim Uttaro =20 -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: Sunday, October 23, 2011 5:32 PM To: idr@ietf.org List Subject: [Idr] draft-uttaro-idr-bgp-persistence-00 =20 Authors, =20 Actually when discussing this draft a new concern surfaced which I would like to get your answer on. =20 The draft in section 4.2 says as one of the forwarding rules: =20 o Forwarding to a "stale" route is only used if there are no other paths available to that route. In other words an active path always wins regardless of path selection. "Stale" state is always considered to be less preferred when compared with an active path. =20 In the light of the above rule let's consider a very simple case of dual PE attached site of L3VPN service. Two CEs would inject into their IBGP mesh routes to the remote destination: one marked as STALE and one not marked at all. (Each CE is connected to different PE and each PE RT imports only a single route to a remote hub headquarter to support geographic load balancing). =20 Let me illustrate: =20 VPN Customer HUB =20 PE3 PE4 SP PE1 PE2 | | | | CE1 CE2 | | 1| |10 | | R1 ------ R2 1 =20 CE1,CE2,R1,R2 are in IBGP mesh. IGP metric of CE1-R1 and R1-R2 are 1 and R2-CE2 is 10. =20 Prefix X is advertised by remote hub in the given VPN such that PE1 vrf towards CE1 only has X via PE3 and PE2's vrf towards CE2 only has X via PE4. =20 Let's assume EBGP sessions PE3 to HUB went down, but ethernet link is up, next hop is in the RIB while data plane is gone. Assume no data plane real validation too. /* That is why in my former message I suggested that data plane validation would be necessary */. =20 R1 has X via PE1/S (stale) and X via PE2/A (active) - it understands STALE so selects in his forwarding table path via CE2. =20 R2 has X via PE1/S (stale) and X via PE2/A (active) - it does not understand STALE, never was upgraded to support the forwarding rule stated above in the draft and chooses X via CE1 (NH metric 2 vs 10). =20 R1--R2 produce data plane loop as long as STALE paths are present in the system. Quite fun to troubleshoot too as the issue of PE3 injecting such STALE paths may be on the opposite site of the world. =20 The issue occurs when some routers within the customer site will be able to recognize STALE transitive community and prefer non stale paths in their forwarding planes (or BGP planes for that matter) while others will not as well as when both stale and non stale paths will be present. =20 Question 1: How do you prevent forwarding loop in such case ? =20 Question 2: How do you prevent forwarding loop in the case when customer would have backup connectivity to his sites or connectivity via different VPN provider yet routers in his site only partially understand the STALE community and only partially follow the forwarding rules ? =20 In general as the rule is about mandating some particular order of path forwarding selection what is the mechanism in distributed systems like today's routing to be able to achieve any assurance that such rule is active and enforced across _all_ routers behind EBGP PE-CE L3VPN boundaries in customer sites ? =20 Best regards, R. =20 =20 -------- Original Message -------- Subject: [Idr] draft-uttaro-idr-bgp-persistence-00 Date: Sat, 22 Oct 2011 00:23:55 +0200 From: Robert Raszuk Reply-To: robert@raszuk.net To: idr@ietf.org List =20 =20 Hi, =20 I have read the draft and have one question and one observation. =20 Question: =20 What is the point of defining DO_NOT_PERSIST community ? In other words why not having PERSIST community set would not mean the same as having path marked with DO_NOT_PERSIST. =20 Observation: =20 I found the below statement in section 4.2: =20 o Forwarding must ensure that the Next Hop to a "stale" route is viable. =20 Of course I agree. But since we stating obvious in the forwarding section I think it would be good to explicitly also state this in the best path selection that next hop to STALE best path must be valid. =20 However sessions especially those between loopbacks do not go down for no reason. Most likely there is network problem which may have caused those sessions to go down. It is therefor likely that LDP session went also down between any of the LSRs in the data path and that in spite of having the paths in BGP and next hops in IGP the LSP required for both quoted L2/L3VPN applications is broken. That may particularly happen when network chooses to use independent control mode for label allocation. =20 I would suggest to at least add the recommendation statement to the document that during best path selection especially for stale paths a validity of required forwarding paradigm to next hop of stale paths should be verified. =20 For example using techniques as described in: draft-ietf-idr-bgp-bestpath-selection-criteria =20 Best regards, R. =20 =20 _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr =20 =20 _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr =20 =20 =20 _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr =20 =20 ------_=_NextPart_001_01CC996D.FD290DEE Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Enke,

 

Please find some comments inlined = [BD]

 

From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Enke Chen
Sent: Friday, October 28, 2011 8:19 AM
To: UTTARO, JAMES
Cc: idr@ietf.org List; robert@raszuk.net
Subject: Re: [Idr] = draft-uttaro-idr-bgp-persistence-00

 

Jim,

My comments are inlined.

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

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

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

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


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

Regarding the use of the STALE state vs ACTIVE state, clearly there is a tradeoff.

[BD] clearly. Cf my previous email.

 

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

[BD] That “simple knob” would contradict the = GR spec “The router MUST NOT  differentiate between stale and other routing information = during   forwarding.”

 


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

[BD] sure. But I fail to see why a set of knobs = independently defined by each implementation would be better than a draft describing the = expected behavior.

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


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



[BD] I’m not sure to understand how changing the =
min stale timer would address this. Again, this “simple =
knob” would contradict the GR spec “To deal with possible =
consecutive restarts, a route (from the peer) previously marked as stale =
MUST be deleted.”
 
 
GR does not employ a =
make before break strategy. All state is invalidated first then the =
newly learned state is processed. This leads to routing churn especially =
if the majority of the state is the same which I am pretty sure is the =
case


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

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

---

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

---

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


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


It has been addressed by the following extension:

http://datatracker.ietf.org/doc/draft-keyupate-idr-bgp-gr-no= tification/

[BD] I would rather have said that this should be = addressed by draft-ietf-idr-optional-transitive-04. (as in case of a malformed update, = draft-keyupate-idr-bgp-gr-notification, would mostly GR restart the BGP session again and again indefinitely). = However, as hard as we try, I would not bet that = draft-ietf-idr-optional-transitive will cover all possible future cases. This is mostly a (good IMHO) reaction = to past issue, rather than a solution to all future issues BGP could have to = face. OTOH, persistence could be the safety net to address the unexpected = issues.

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


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

[BD] Indeed. I think this should be clarify in the GR = spec. Could you please clarify this in = draft-chen-idr-rfc4724bis-00.txt?



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


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


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


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

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

[BD] It’s advertised in the GR capability and = bounded by the 12 bits fields. Eventually, you could have local knob to override every GR = behavior, but I would not call this GR anymore.



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


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

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


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


Except for the path level persistence you mentioned, I believe the GR = will be able to address all other persistence requirements you listed, with some = simple knobs and some implementation enhancements.
[BD] What about calling “persistence” this = set of “simple knobs and implementation enhancements”?

Regards,
Bruno
 
Thanks,
       Jim =
Uttaro


Thanks.   -- Enke


 
 
-----Original =
Message-----
From: Enke Chen [mailto:enkechen@cisco.com] =

Sent: Wednesday, October 26, 2011 8:43 =
PM
To: UTTARO, JAMES
Cc: robert@raszuk.net; idr@ietf.org List; Enke =
Chen
Subject: Re: [Idr] =
draft-uttaro-idr-bgp-persistence-00
 
Hi, =
folks:
 
I have a hard =
time in understanding what new problems (beyond the GR) =

the draft try to solve =
:-(
 
If the concern is =
about the simultaneous RR failure as shown in the =

examples in Sect. 6 Application, that can be =
addressed easily using GR.  
As the RRs are =
not in the forwarding path, it means that the forwarding =

is not impacted (thus is preserved) during the =
restart of a RR.   The 
Forwarding State =
bit (F) in the GR capability should always be set by =

the RR when it is not in the forwarding =
path.
 
Also in the case =
of simultaneous RR failure, I do not see why one would =

want to retain some routes, but not others, using =
the communities 
specified in the draft.  As =
the RRs are not in the forwarding path, 
wouldn't =
be better to retain all the routes on a =
PE/client?
 
As you might =
be aware, efforts have been underway to address issues with =

GR found during implementation and deployment. =
They include the spec 
respin, notification =
handling, and implementations.  If there are issues =

in the GR area that are not adequately =
addressed,  I suggest that we try 
to address =
them in the GR respin if possible, instead of creating =

another variation =
unnecessarily.
 
Thanks.&n=
bsp;  -- =
Enke
 
 
On 10/26/11 10:24 AM, Robert Raszuk wrote:



Jim,
=

 
When one during design phase of a =
routing protocol or routing protocol 
extension or =
modification to it already realizes that enabling such =

feature may cause real network issue if not done =
carefully - that 
should trigger the alarm to =
rethink the solution and explore 
alternative =
approaches to the problem =
space.
 
We as operators =
have already hard time to relate enabling a feature =

within our intradomain boundaries to make sure =
such rollout is network 
wide. Here you are asking =
for the same level of awareness across ebgp =

boundaries. This is practically unrealistic =
IMHO.
 
Back to the =
proposal ... I think that if anything needs to be done is =

to employ per prefix GR with longer and locally =
configurable timer. 
That would address information =
persistence across direct IBGP =
sessions.
 
On the RRs =
use case of this draft we may perhaps agree to disagree, =

but I do not see large enough probability of =
correctly engineered RR 
plane to experience =
simultaneous multiple ibgp session drops. If that =

happens the RR placement, platforms or deployment =
model should be =

re-engineered.
 
Summary .. I do not think that IDR WG should adopt this =
document. Just 
adding a warning to the deployment =
section is not =
sufficient.
 
Best =
regards,
R.
 
 



Robert,
 
The introduction of this technology =
needs to be carefully evaluated
when being deployed =
into the network. Your example clearly calls =
out
how a series of independent design can =
culminate in incorrect
behavior. Certainly the =
deployment of persistence on a router that
has =
interaction with a router that does not needs to be =
clearly
understood by the network designer. The =
goal of this draft is to
provide a fairly =
sophisticated tool that will protect the majority =
of
customers in the event of a catastrophic =
failure.. The premise being
the perfect is not the =
enemy of the good.. I will add text in =
the
deployment considerations section to better =
articulate =
that..
 
Thanks, Jim =
Uttaro
 
-----Original =
Message----- From: idr-bounces@ietf.org<=
/pre>
[mailto:idr-bounces@ietf.org] On =
Behalf Of Robert Raszuk Sent:
Sunday, October 23, =
2011 5:32 PM To: idr@ietf.org List Subject: =
[Idr]
draft-uttaro-idr-bgp-persistence-00=

 
Authors,
 
Actually when discussing this draft a new =
concern surfaced which I
would like to get your =
answer on.
 
The draft in =
section 4.2 says as one of the forwarding =
rules:
 
o  =
Forwarding to a "stale" route is only used if there are no =
other
paths available to that route.  In other =
words an active path always
wins regardless of path =
selection.  "Stale" state is =
always
considered to be less preferred when =
compared with an active =
path.
 
In the light of =
the above rule let's consider a very simple case =
of
dual PE attached site of L3VPN service. Two CEs =
would inject into
their IBGP mesh routes to the =
remote destination: one marked as STALE
and  =
one not marked at all. (Each CE is connected to different PE =
and
each PE RT imports only a single route to a =
remote hub headquarter to
support geographic load =
balancing).
 
Let me =
illustrate:
 
VPN =
Customer =
HUB
 
PE3   =
;   PE4 SP PE1      PE2 =
|        | =
|        | =
CE1      CE2 |
| =
1|        |10 =
|        | R1 ------ R2 =
1
 
CE1,CE2,R1,R2 are in =
IBGP mesh. IGP metric of CE1-R1 and R1-R2 are 1
and =
R2-CE2 is 10.
 
Prefix X =
is advertised by remote hub in the given VPN such that =
PE1
vrf towards CE1 only has X via PE3 and PE2's =
vrf towards CE2 only has
X via =
PE4.
 
Let's assume EBGP =
sessions PE3 to HUB went down, but ethernet link
is =
up, next hop is in the RIB while data plane is gone. Assume =
no
data plane real validation too. /* That is why =
in my former message
I suggested that data plane =
validation would be necessary =
*/.
 
R1 has X via PE1/S =
(stale) and X via PE2/A (active) - it =
understands
STALE so selects in his forwarding =
table path via CE2.
 
R2 =
has X via PE1/S (stale) and X via PE2/A (active) - it does =
not
understand STALE, never was upgraded to support =
the forwarding rule
stated above in the draft and =
chooses X via CE1 (NH metric 2 vs =
10).
 
R1--R2 produce =
data plane loop as long as STALE paths are present =
in
the system. Quite fun to troubleshoot too as the =
issue of PE3
injecting such STALE paths may be on =
the opposite site of the =
world.
 
The issue occurs =
when some routers within the customer site will =
be
able to recognize STALE transitive community and =
prefer non stale
paths in their forwarding planes =
(or BGP planes for that matter)
while others will =
not as well as when both stale and non stale =
paths
will be =
present.
 
Question 1: =
How do you prevent forwarding loop in such case =
?
 
Question 2: How do =
you prevent forwarding loop in the case =
when
customer would have backup connectivity to his =
sites or connectivity
via different VPN provider =
yet routers in his site only partially
understand =
the STALE community and only partially follow =
the
forwarding rules =
?
 
In general as the =
rule is about mandating some particular order =
of
path forwarding selection what is the mechanism =
in distributed
systems like today's routing to be =
able to achieve any assurance that
such rule is =
active and enforced across _all_ routers behind =
EBGP
PE-CE L3VPN boundaries in customer sites =
?
 
Best regards, =
R.
 
 
-------- Original Message -------- Subject: =
[Idr]
draft-uttaro-idr-bgp-persistence-00 Date: =
Sat, 22 Oct 2011 00:23:55
+0200 From: Robert =
Raszuk<robert@raszuk.net> =
Reply-To:
robert@raszuk.net To: idr@ietf.org List<idr@ietf.org>
 
Hi,
 <=
/pre>
I have read the draft and have one question and one =
observation.
 
Question:
 
What is the point of =
defining DO_NOT_PERSIST community ? In other
words =
why not having PERSIST community set would not mean the same =
as
having path marked with =
DO_NOT_PERSIST.
 
Observat=
ion:
 
I found the below =
statement in section =
4.2:
 
o  Forwarding =
must ensure that the Next Hop to a "stale" route =
is
viable.
 
Of course I agree. But since we stating obvious in the =
forwarding
section I think it would be good to =
explicitly also state this in
the best path =
selection that next hop to STALE best path must =
be
valid.
 
However sessions especially those between loopbacks do not go =
down
for no reason. Most likely there is network =
problem which may have
caused those sessions to go =
down. It is therefor likely that LDP
session went =
also down between any of the LSRs in the data path =
and
that in spite of having the paths in BGP and =
next hops in IGP the LSP
required for both quoted =
L2/L3VPN applications is broken. That =
may
particularly happen when network chooses to use =
independent control
mode for label =
allocation.
 
I would =
suggest to at least add the recommendation statement to =
the
document that during best path selection =
especially for stale paths
a validity of required =
forwarding paradigm to next hop of stale
paths =
should be verified.
 
For =
example using techniques as described =
in:
draft-ietf-idr-bgp-bestpath-selection-criteria
 
Best regards, =
R.
 
 
_______________________________________________ Idr mailing =
list
Idr@ietf.org https://www.ietf.org/m=
ailman/listinfo/idr
 
=
 
_____________________________________________=
__ Idr mailing list
Idr@ietf.org https://www.ietf.org/m=
ailman/listinfo/idr
 
=
 



 
________________________________________=
_______
Idr mailing list
Idr@ietf.org
https://www.ietf.org/m=
ailman/listinfo/idr



 



 
------_=_NextPart_001_01CC996D.FD290DEE-- From robert@raszuk.net Wed Nov 2 07:47:06 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA10611E80B6 for ; Wed, 2 Nov 2011 07:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HK8Bd9vQtzRZ for ; Wed, 2 Nov 2011 07:47:05 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id 3FD2211E80E7 for ; Wed, 2 Nov 2011 07:47:05 -0700 (PDT) Received: (qmail 14754 invoked by uid 399); 2 Nov 2011 14:47:04 -0000 Received: from unknown (HELO ?192.168.1.52?) (83.31.220.67) by mail37.opentransfer.com with SMTP; 2 Nov 2011 14:47:04 -0000 Message-ID: <4EB157DA.8010902@raszuk.net> Date: Wed, 02 Nov 2011 15:46:50 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: bruno.decraene@orange.com References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net><4EA84254.9000400@raszuk.net> <4EA8A91C.4090305@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 14:47:06 -0000 Bruno, > Indeed, possibly the persistence requirements could be inserted in the > GR draft. Really ? I find this totally opposite. GR can be very useful without persistence draft. But how persistent draft be of any use without assuring even at the given router proper forwarding ? So correct me if I am not mistaken. Imagine following sequence of events: - PE operates fine GR is not enable and persistence is - PE looses session to RRs as RRs goes down - PE keeps all routes in control plane and data plane (no GR involved) - PE re-advertises all routes (for given AFI/SAFI) to all 1000 of CEs marked as STALE - PE re-establishes IBGP sessions with RRs and effectively performs GR invalid path removal Is this correct ? If so then end result is double churn to 1000 CEs and reuse of the main GR re-sync specification without enabling GR. Moreover with this you are relaxing the need for any capability negotiation. Perhaps GR authors could clarify why did we need in the first place per SAFI GR capability negotiation. Going by your draft just global GR / EOR marker would be sufficient. I don't recall any discussion on that point in persistent draft too. Cheers, R. > Hi Enke, > >> From: Enke Chen; Sent: Thursday, October 27, 2011 2:43 AM >> >> Hi, folks: >> >> I have a hard time in understanding what new problems (beyond the GR) >> the draft try to solve :-( > > That's a good comment. Do you think the draft should put both GR and > persistence into perspective? (e.g. either in the introduction or in > appendix) > >> If the concern is about the simultaneous RR failure as shown in the >> examples in Sect. 6 Application, that can be addressed easily using GR. >> As the RRs are not in the forwarding path, it means that the forwarding >> is not impacted (thus is preserved) during the restart of a RR. The >> Forwarding State bit (F) in the GR capability should always be set by >> the RR when it is not in the forwarding path. > > GR has limitations: limited duration, does not handle consecutive > session restarts, (currently) does not handle BGP failures, does not > advertise that the STALE path may be less trusted. > >> Also in the case of simultaneous RR failure, I do not see why one would >> want to retain some routes, but not others, using the communities >> specified in the draft. As the RRs are not in the forwarding path, >> wouldn't be better to retain all the routes on a PE/client? > > I find interesting that you considered that all routes would be kept > STALE for a long time. I was rather anticipating that some people would > be uncomfortable with this, especially in the VPN cases as correct and > up to date routing information are required to ensure isolation between > VPNs. (cf security section of the persistence draft). > Regarding your point, some route could be fairly static and hence kept > STALE for a long time. Other routes may be more dynamic and more > problematic to keep STALE for a long time. Hence the ability for a > different response. Also, some route may be more critical than others. > >> As you might be aware, efforts have been underway to address issues > with >> GR found during implementation and deployment. They include the spec >> respin, notification handling, and implementations. If there are > issues >> in the GR area that are not adequately addressed, I suggest that we > try >> to address them in the GR respin if possible, instead of creating >> another variation unnecessarily. > > Indeed, possibly the persistence requirements could be inserted in the > GR draft. But how much are you / IDR WG ready to change that much the GR > procedures? That would basically force all GR implementations to > implement the persistence behavior. > > Besides, IMHO, GR and persistence make different assumptions and hence > are rather different: > - GR assumes that the forwarding is preserved during the BGP session > restart and hence decides to not advertise this event in the network. > For such assumption, you need to believe pretty strongly that the > forwarding is indeed preserved. IMHO this calls for a short timer > duration and quick fall back to session failure if you suspect this may > not be the case (e.g. in case of consecutive restart of the BGP session, > GR is aborted). > - "persistence" considers that in case of issues, some stale information > is better than no information, but worst than correct information. The > downside is BGP churn to advertise the event. The good side is that this > is a safer assumption hence more likely to be valid over time or events. > > Regards, > Bruno > >> >> Thanks. -- Enke >> >> >> On 10/26/11 10:24 AM, Robert Raszuk wrote: >>> Jim, >>> >>> When one during design phase of a routing protocol or routing > protocol >>> extension or modification to it already realizes that enabling such >>> feature may cause real network issue if not done carefully - that >>> should trigger the alarm to rethink the solution and explore >>> alternative approaches to the problem space. >>> >>> We as operators have already hard time to relate enabling a feature >>> within our intradomain boundaries to make sure such rollout is > network >>> wide. Here you are asking for the same level of awareness across ebgp >>> boundaries. This is practically unrealistic IMHO. >>> >>> Back to the proposal ... I think that if anything needs to be done is >>> to employ per prefix GR with longer and locally configurable timer. >>> That would address information persistence across direct IBGP > sessions. >>> >>> On the RRs use case of this draft we may perhaps agree to disagree, >>> but I do not see large enough probability of correctly engineered RR >>> plane to experience simultaneous multiple ibgp session drops. If that >>> happens the RR placement, platforms or deployment model should be >>> re-engineered. >>> >>> Summary .. I do not think that IDR WG should adopt this document. > Just >>> adding a warning to the deployment section is not sufficient. >>> >>> Best regards, >>> R. >>> >>> >>>> Robert, >>>> >>>> The introduction of this technology needs to be carefully evaluated >>>> when being deployed into the network. Your example clearly calls out >>>> how a series of independent design can culminate in incorrect >>>> behavior. Certainly the deployment of persistence on a router that >>>> has interaction with a router that does not needs to be clearly >>>> understood by the network designer. The goal of this draft is to >>>> provide a fairly sophisticated tool that will protect the majority > of >>>> customers in the event of a catastrophic failure.. The premise being >>>> the perfect is not the enemy of the good.. I will add text in the >>>> deployment considerations section to better articulate that.. >>>> >>>> Thanks, Jim Uttaro >>>> >>>> -----Original Message----- From: idr-bounces@ietf.org >>>> [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: >>>> Sunday, October 23, 2011 5:32 PM To: idr@ietf.org List Subject: > [Idr] >>>> draft-uttaro-idr-bgp-persistence-00 >>>> >>>> Authors, >>>> >>>> Actually when discussing this draft a new concern surfaced which I >>>> would like to get your answer on. >>>> >>>> The draft in section 4.2 says as one of the forwarding rules: >>>> >>>> o Forwarding to a "stale" route is only used if there are no other >>>> paths available to that route. In other words an active path always >>>> wins regardless of path selection. "Stale" state is always >>>> considered to be less preferred when compared with an active path. >>>> >>>> In the light of the above rule let's consider a very simple case of >>>> dual PE attached site of L3VPN service. Two CEs would inject into >>>> their IBGP mesh routes to the remote destination: one marked as > STALE >>>> and one not marked at all. (Each CE is connected to different PE > and >>>> each PE RT imports only a single route to a remote hub headquarter > to >>>> support geographic load balancing). >>>> >>>> Let me illustrate: >>>> >>>> VPN Customer HUB >>>> >>>> PE3 PE4 SP PE1 PE2 | | | | CE1 CE2 | >>>> | 1| |10 | | R1 ------ R2 1 >>>> >>>> CE1,CE2,R1,R2 are in IBGP mesh. IGP metric of CE1-R1 and R1-R2 are 1 >>>> and R2-CE2 is 10. >>>> >>>> Prefix X is advertised by remote hub in the given VPN such that PE1 >>>> vrf towards CE1 only has X via PE3 and PE2's vrf towards CE2 only > has >>>> X via PE4. >>>> >>>> Let's assume EBGP sessions PE3 to HUB went down, but ethernet link >>>> is up, next hop is in the RIB while data plane is gone. Assume no >>>> data plane real validation too. /* That is why in my former message >>>> I suggested that data plane validation would be necessary */. >>>> >>>> R1 has X via PE1/S (stale) and X via PE2/A (active) - it understands >>>> STALE so selects in his forwarding table path via CE2. >>>> >>>> R2 has X via PE1/S (stale) and X via PE2/A (active) - it does not >>>> understand STALE, never was upgraded to support the forwarding rule >>>> stated above in the draft and chooses X via CE1 (NH metric 2 vs 10). >>>> >>>> R1--R2 produce data plane loop as long as STALE paths are present in >>>> the system. Quite fun to troubleshoot too as the issue of PE3 >>>> injecting such STALE paths may be on the opposite site of the world. >>>> >>>> The issue occurs when some routers within the customer site will be >>>> able to recognize STALE transitive community and prefer non stale >>>> paths in their forwarding planes (or BGP planes for that matter) >>>> while others will not as well as when both stale and non stale paths >>>> will be present. >>>> >>>> Question 1: How do you prevent forwarding loop in such case ? >>>> >>>> Question 2: How do you prevent forwarding loop in the case when >>>> customer would have backup connectivity to his sites or connectivity >>>> via different VPN provider yet routers in his site only partially >>>> understand the STALE community and only partially follow the >>>> forwarding rules ? >>>> >>>> In general as the rule is about mandating some particular order of >>>> path forwarding selection what is the mechanism in distributed >>>> systems like today's routing to be able to achieve any assurance > that >>>> such rule is active and enforced across _all_ routers behind EBGP >>>> PE-CE L3VPN boundaries in customer sites ? >>>> >>>> Best regards, R. >>>> >>>> >>>> -------- Original Message -------- Subject: [Idr] >>>> draft-uttaro-idr-bgp-persistence-00 Date: Sat, 22 Oct 2011 00:23:55 >>>> +0200 From: Robert Raszuk Reply-To: >>>> robert@raszuk.net To: idr@ietf.org List >>>> >>>> Hi, >>>> >>>> I have read the draft and have one question and one observation. >>>> >>>> Question: >>>> >>>> What is the point of defining DO_NOT_PERSIST community ? In other >>>> words why not having PERSIST community set would not mean the same > as >>>> having path marked with DO_NOT_PERSIST. >>>> >>>> Observation: >>>> >>>> I found the below statement in section 4.2: >>>> >>>> o Forwarding must ensure that the Next Hop to a "stale" route is >>>> viable. >>>> >>>> Of course I agree. But since we stating obvious in the forwarding >>>> section I think it would be good to explicitly also state this in >>>> the best path selection that next hop to STALE best path must be >>>> valid. >>>> >>>> However sessions especially those between loopbacks do not go down >>>> for no reason. Most likely there is network problem which may have >>>> caused those sessions to go down. It is therefor likely that LDP >>>> session went also down between any of the LSRs in the data path and >>>> that in spite of having the paths in BGP and next hops in IGP the > LSP >>>> required for both quoted L2/L3VPN applications is broken. That may >>>> particularly happen when network chooses to use independent control >>>> mode for label allocation. >>>> >>>> I would suggest to at least add the recommendation statement to the >>>> document that during best path selection especially for stale paths >>>> a validity of required forwarding paradigm to next hop of stale >>>> paths should be verified. >>>> >>>> For example using techniques as described in: >>>> draft-ietf-idr-bgp-bestpath-selection-criteria >>>> >>>> Best regards, R. >>>> From bruno.decraene@orange.com Wed Nov 2 08:35:03 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDD21F0C78 for ; Wed, 2 Nov 2011 08:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L28jRmQ+eJ9w for ; Wed, 2 Nov 2011 08:35:03 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id C76001F0C6B for ; Wed, 2 Nov 2011 08:35:01 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CD66B8B8005; Wed, 2 Nov 2011 16:36:23 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id C29FA6C0004; Wed, 2 Nov 2011 16:36:23 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Nov 2011 16:35:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Nov 2011 16:35:00 +0100 Message-ID: In-Reply-To: <4EB147F6.1090906@raszuk.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-00 Thread-Index: AcyZZNNUR1HYv4gSQgqAtruOil2n9AAD0xbw References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net> <4EB147F6.1090906@raszuk.net> From: To: X-OriginalArrivalTime: 02 Nov 2011 15:35:00.0991 (UTC) FILETIME=[FBFE60F0:01CC9974] Cc: idr@ietf.org Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 15:35:03 -0000 Hi Robert, >From: Robert Raszuk [mailto:robert@raszuk.net] >Sent: Wednesday, November 02, 2011 2:39 PM > >Hi Bruno, > > > Nope. In your above case, I would expect the failure to be concealed > > within the SP AS: > > > > PE1 has X via PE1/S (stale) and X via PE2/A (active) - it understands > > STALE so selects in his forwarding table path via PE2. > > > > --> The customer does not see the "STALE" information. > >Nope - it sure does. > >As I have obviously foreseen you are going to say so I specifically >pointed out that there is no symmetry on the PEs due to the specific RT >configuration. See below quote: > >"Prefix X is advertised by remote hub in the given VPN such that PE1 vrf >towards CE1 only has X via PE3 and PE2's vrf towards CE2 only has X via >PE4." Ok. I thought you were using local pref to influence routing decision. If you actually remove the other route by RT configuration, this is indeed different and the customer will see the STALE information. Looks to me a very specific case as in you topology, a failure/maintenance in the remote hub site and in the MH site could lead to network unavailability (e.g. failure of PE3/CE3/PE3-CE3 link and PE2/CE2/PE2-Ce link) VPN Customer HUB PE3 PE4 SP PE1 PE2 | | However, that does not change the below discussion as I had not dismissed your argument. >> You bring the issue of the incremental deployment of a feature which >> change the (BGP) routing decision. That's a valid point (not necessarily >> specific to the persistence draft). > >I think any draft modifying routing decision should discuss such issues. > >> One answer is careful deployment of such features. > >I am afraid this is very difficult to achieve across EBGP boundaries. If >you would just limit STALE to IBGP I would perhaps have a bit lighter >objection :) > >> However I the persistence draft could probably be improved to handles >> incremental deployment. This could be addressed in the next revision. >> A first tentative could be: >> - over an iBGP session, the router detecting the BGP session failure, >> flag the routes with a low (e.g. 0) LOCAL_PREF plus the STALE community. >> Within the AS, the STALE community does not influence routing decision >> but inform possible downstream BGP routers of the cause of the low >> local_pref. In particular that the LOCAL_PREF should probably not be >> further changed (some AS handles load balancing by rewriting the Local >> Pref on the ingress PE) >> - inform downstream AS of the STALE condition. First eBGP router could >> translate this community into a low local_pref. With the iBGP mesh, cf >> above. > >Translating STALE to Local Pref over EBGP and not using STALE for local >decision makes the proposal much less dangerous indeed. > >Is any action associated with STALE going to be disabled by default in >all BGP implementations ? If yes I would see it acceptable - provided >the above changes are introduced. I'm happy that you would find the persistence proposal acceptable. We'll work on this on the next revision. Many thanks for bringing this valid point. >However if any implementation is going to enable auto translation of >STALE to local pref =3D 0 across EBGP boundary, or make best path decision >based on STALE presence - we have the same problem as soon as any two >routers are not upgraded in the same time to the same vendor's code >version. > >-- > >Regardless how novel and appealing is the idea of telling your customer >that you can possibly forward, but your control plane is undergoing >recovery - I still think that churn introduced by this sort of >signalling on a per path basis is a pretty bad idea. If anything I would >rather see this in the BGP Operational Message not in the actual routing >UPDATE messages. > >Cheers, >R. From bruno.decraene@orange.com Wed Nov 2 09:34:01 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDF6721F9E76 for ; Wed, 2 Nov 2011 09:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OaQLStXB3Ibu for ; Wed, 2 Nov 2011 09:34:01 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 32F8421F9E2D for ; Wed, 2 Nov 2011 09:34:01 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 86A3FFDC002; Wed, 2 Nov 2011 17:33:59 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 7B8DFFDC001; Wed, 2 Nov 2011 17:33:59 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Nov 2011 17:33:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Nov 2011 17:33:58 +0100 Message-ID: In-Reply-To: <4EB14BDD.7040802@raszuk.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-00 Thread-Index: AcyZZyVed1J5CCjwQy+7RLsiJak/tQAFPu4A References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net> <4EA84254.9000400@raszuk.net> <4EB14BDD.7040802@raszuk.net> From: To: X-OriginalArrivalTime: 02 Nov 2011 16:33:59.0489 (UTC) FILETIME=[391A5310:01CC997D] Cc: idr@ietf.org, ju1738@att.com Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 16:34:02 -0000 Robert, >Bruno, > >> The low chance / probability of the failure of both RR planes is indeed >> a good point. I can also agree that this is expected to be low. I >> disagree that it never happens. E.g. with current BGP error handling, >> the same BGP attribute in "error" would cause both iBGP plane to go >> down. Hopefully work is being done to improve this. But I would not bet >> that this will cover all future cases. > >If trigger is due to malformed update why are we so concerned about RRs? We are concerned about RR-PE sessions because if the sessions are down, all routes are down. PEs become essentially useless. >Wouldn't equally susceptible be also PEs/ASBRs ? Indeed, inter AS VPN eBGP session are also important. (although you would one use the inter AS routes and hence PE/VPN are still useable. >And the cure that those is GR, not persistence ;). Cf Enke's thread. >> In such catastrophic cases, some routing is better than no routing. > >I don't know about that. > >> On a side note, considering that the RR and hence their failure are >> independent and therefore will quite never fail at the same time, is >> questionable. To start with, they process they mostly process the same >> input (BGP updates) and are part of the same network. > >I don't think I used the term "never".=20 Ok. >But with dual or triple vendor >control plane the probability of RR network wide outage drops >significantly lower. Sure. But given the small number of RR boxes, and the high requirements on these boxes, it's harder to justify a two or three vendor sourcing. Cheers, Bruno >Cheers, >R. From bruno.decraene@orange.com Wed Nov 2 09:53:12 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD82211E80B3 for ; Wed, 2 Nov 2011 09:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Nr9XPuxdZiQ for ; Wed, 2 Nov 2011 09:53:11 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id DC5FB11E8090 for ; Wed, 2 Nov 2011 09:53:10 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DEEDD9B0007; Wed, 2 Nov 2011 17:54:08 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 4ADDF9B0005; Wed, 2 Nov 2011 17:52:13 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Nov 2011 17:51:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Nov 2011 17:51:08 +0100 Message-ID: In-Reply-To: <4EB157DA.8010902@raszuk.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-00 Thread-Index: AcyZbkuY+T5FKov2SV2ZEFAERnozggADyaJA References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net><4EA84254.9000400@raszuk.net> <4EA8A91C.4090305@cisco.com> <4EB157DA.8010902@raszuk.net> From: To: X-OriginalArrivalTime: 02 Nov 2011 16:51:09.0653 (UTC) FILETIME=[9F20E050:01CC997F] Cc: idr@ietf.org Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 16:53:12 -0000 Robert, >Bruno, > > > Indeed, possibly the persistence requirements could be inserted in = the > > GR draft. > >Really ? I find this totally opposite. > >GR can be very useful without persistence draft. That was mostly my point. Sorry if I didn't make it clear. > But how persistent >draft be of any use without assuring even at the given router proper >forwarding ? For an eBGP session, I agree forwarding should be more or less trusted = as running. (even if this is not strictly required given all routers = will select the other path. Cf my previous email) >So correct me if I am not mistaken. Imagine following sequence of = events: > >- PE operates fine GR is not enable and persistence is >- PE looses session to RRs as RRs goes down >- PE keeps all routes in control plane and data plane (no GR involved) >- PE re-advertises all routes (for given AFI/SAFI) to all 1000 of CEs > marked as STALE >- PE re-establishes IBGP sessions with RRs and effectively performs GR > invalid path removal > > >Is this correct ? No. Interaction between GR and persistence is currently not described in = this version. It will be in the next version. In short, if GR & persistence were enabled both on a BGP session, GR = would first run. Then if GR does not succeed, persistence would come = into play. >If so then end result is double churn to 1000 CEs and reuse of the main >GR re-sync specification without enabling GR. No. If GR success, there would be no churn. Otherwise, single churn >Moreover with this you are relaxing the need for any capability >negotiation. Perhaps GR authors could clarify why did we need in the >first place per SAFI GR capability negotiation. Going by your draft = just >global GR / EOR marker would be sufficient.=20 Indeed, no capability negotiation is required. We only need EOR. In v00, = it has been assumed that EOR is now a standard behavior. Otherwise we = could explicitly signal this using the GR capability. >I don't recall any >discussion on that point in persistent draft too. " A speaker configures the ability to persist independently of it's peer. There is no negotiation between the peers. A timer must be configured indicating the time to persist stale state from a peer where the session is no longer viable. " =A73 = http://tools.ietf.org/html/draft-uttaro-idr-bgp-persistence-00#page-6 " o The Receiving Speaker MUST replace the stale routes by the = routing updates received from the peer. Once the End-of-RIB marker for an address family is received from the peer, it MUST immediately remove any paths from the peer that are still marked as stale for that address family." =A74.2 = http://tools.ietf.org/html/draft-uttaro-idr-bgp-persistence-00#section-4.= 2 Cheers, Bruno >Cheers, >R. > >> Hi Enke, >> >>> From: Enke Chen; Sent: Thursday, October 27, 2011 2:43 AM >>> >>> Hi, folks: >>> >>> I have a hard time in understanding what new problems (beyond the = GR) >>> the draft try to solve :-( >> >> That's a good comment. Do you think the draft should put both GR and >> persistence into perspective? (e.g. either in the introduction or in >> appendix) >> >>> If the concern is about the simultaneous RR failure as shown in the >>> examples in Sect. 6 Application, that can be addressed easily using = GR. >>> As the RRs are not in the forwarding path, it means that the = forwarding >>> is not impacted (thus is preserved) during the restart of a RR. = The >>> Forwarding State bit (F) in the GR capability should always be set = by >>> the RR when it is not in the forwarding path. >> >> GR has limitations: limited duration, does not handle consecutive >> session restarts, (currently) does not handle BGP failures, does not >> advertise that the STALE path may be less trusted. >> >>> Also in the case of simultaneous RR failure, I do not see why one = would >>> want to retain some routes, but not others, using the communities >>> specified in the draft. As the RRs are not in the forwarding path, >>> wouldn't be better to retain all the routes on a PE/client? >> >> I find interesting that you considered that all routes would be kept >> STALE for a long time. I was rather anticipating that some people = would >> be uncomfortable with this, especially in the VPN cases as correct = and >> up to date routing information are required to ensure isolation = between >> VPNs. (cf security section of the persistence draft). >> Regarding your point, some route could be fairly static and hence = kept >> STALE for a long time. Other routes may be more dynamic and more >> problematic to keep STALE for a long time. Hence the ability for a >> different response. Also, some route may be more critical than = others. >> >>> As you might be aware, efforts have been underway to address issues >> with >>> GR found during implementation and deployment. They include the spec >>> respin, notification handling, and implementations. If there are >> issues >>> in the GR area that are not adequately addressed, I suggest that we >> try >>> to address them in the GR respin if possible, instead of creating >>> another variation unnecessarily. >> >> Indeed, possibly the persistence requirements could be inserted in = the >> GR draft. But how much are you / IDR WG ready to change that much the = GR >> procedures? That would basically force all GR implementations to >> implement the persistence behavior. >> >> Besides, IMHO, GR and persistence make different assumptions and = hence >> are rather different: >> - GR assumes that the forwarding is preserved during the BGP session >> restart and hence decides to not advertise this event in the network. >> For such assumption, you need to believe pretty strongly that the >> forwarding is indeed preserved. IMHO this calls for a short timer >> duration and quick fall back to session failure if you suspect this = may >> not be the case (e.g. in case of consecutive restart of the BGP = session, >> GR is aborted). >> - "persistence" considers that in case of issues, some stale = information >> is better than no information, but worst than correct information. = The >> downside is BGP churn to advertise the event. The good side is that = this >> is a safer assumption hence more likely to be valid over time or = events. >> >> Regards, >> Bruno >> >>> >>> Thanks. -- Enke >>> >>> >>> On 10/26/11 10:24 AM, Robert Raszuk wrote: >>>> Jim, >>>> >>>> When one during design phase of a routing protocol or routing >> protocol >>>> extension or modification to it already realizes that enabling such >>>> feature may cause real network issue if not done carefully - that >>>> should trigger the alarm to rethink the solution and explore >>>> alternative approaches to the problem space. >>>> >>>> We as operators have already hard time to relate enabling a feature >>>> within our intradomain boundaries to make sure such rollout is >> network >>>> wide. Here you are asking for the same level of awareness across = ebgp >>>> boundaries. This is practically unrealistic IMHO. >>>> >>>> Back to the proposal ... I think that if anything needs to be done = is >>>> to employ per prefix GR with longer and locally configurable timer. >>>> That would address information persistence across direct IBGP >> sessions. >>>> >>>> On the RRs use case of this draft we may perhaps agree to disagree, >>>> but I do not see large enough probability of correctly engineered = RR >>>> plane to experience simultaneous multiple ibgp session drops. If = that >>>> happens the RR placement, platforms or deployment model should be >>>> re-engineered. >>>> >>>> Summary .. I do not think that IDR WG should adopt this document. >> Just >>>> adding a warning to the deployment section is not sufficient. >>>> >>>> Best regards, >>>> R. >>>> >>>> >>>>> Robert, >>>>> >>>>> The introduction of this technology needs to be carefully = evaluated >>>>> when being deployed into the network. Your example clearly calls = out >>>>> how a series of independent design can culminate in incorrect >>>>> behavior. Certainly the deployment of persistence on a router that >>>>> has interaction with a router that does not needs to be clearly >>>>> understood by the network designer. The goal of this draft is to >>>>> provide a fairly sophisticated tool that will protect the majority >> of >>>>> customers in the event of a catastrophic failure.. The premise = being >>>>> the perfect is not the enemy of the good.. I will add text in the >>>>> deployment considerations section to better articulate that.. >>>>> >>>>> Thanks, Jim Uttaro >>>>> >>>>> -----Original Message----- From: idr-bounces@ietf.org >>>>> [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: >>>>> Sunday, October 23, 2011 5:32 PM To: idr@ietf.org List Subject: >> [Idr] >>>>> draft-uttaro-idr-bgp-persistence-00 >>>>> >>>>> Authors, >>>>> >>>>> Actually when discussing this draft a new concern surfaced which I >>>>> would like to get your answer on. >>>>> >>>>> The draft in section 4.2 says as one of the forwarding rules: >>>>> >>>>> o Forwarding to a "stale" route is only used if there are no = other >>>>> paths available to that route. In other words an active path = always >>>>> wins regardless of path selection. "Stale" state is always >>>>> considered to be less preferred when compared with an active path. >>>>> >>>>> In the light of the above rule let's consider a very simple case = of >>>>> dual PE attached site of L3VPN service. Two CEs would inject into >>>>> their IBGP mesh routes to the remote destination: one marked as >> STALE >>>>> and one not marked at all. (Each CE is connected to different PE >> and >>>>> each PE RT imports only a single route to a remote hub headquarter >> to >>>>> support geographic load balancing). >>>>> >>>>> Let me illustrate: >>>>> >>>>> VPN Customer HUB >>>>> >>>>> PE3 PE4 SP PE1 PE2 | | | | CE1 CE2 | >>>>> | 1| |10 | | R1 ------ R2 1 >>>>> >>>>> CE1,CE2,R1,R2 are in IBGP mesh. IGP metric of CE1-R1 and R1-R2 are = 1 >>>>> and R2-CE2 is 10. >>>>> >>>>> Prefix X is advertised by remote hub in the given VPN such that = PE1 >>>>> vrf towards CE1 only has X via PE3 and PE2's vrf towards CE2 only >> has >>>>> X via PE4. >>>>> >>>>> Let's assume EBGP sessions PE3 to HUB went down, but ethernet link >>>>> is up, next hop is in the RIB while data plane is gone. Assume no >>>>> data plane real validation too. /* That is why in my former = message >>>>> I suggested that data plane validation would be necessary */. >>>>> >>>>> R1 has X via PE1/S (stale) and X via PE2/A (active) - it = understands >>>>> STALE so selects in his forwarding table path via CE2. >>>>> >>>>> R2 has X via PE1/S (stale) and X via PE2/A (active) - it does not >>>>> understand STALE, never was upgraded to support the forwarding = rule >>>>> stated above in the draft and chooses X via CE1 (NH metric 2 vs = 10). >>>>> >>>>> R1--R2 produce data plane loop as long as STALE paths are present = in >>>>> the system. Quite fun to troubleshoot too as the issue of PE3 >>>>> injecting such STALE paths may be on the opposite site of the = world. >>>>> >>>>> The issue occurs when some routers within the customer site will = be >>>>> able to recognize STALE transitive community and prefer non stale >>>>> paths in their forwarding planes (or BGP planes for that matter) >>>>> while others will not as well as when both stale and non stale = paths >>>>> will be present. >>>>> >>>>> Question 1: How do you prevent forwarding loop in such case ? >>>>> >>>>> Question 2: How do you prevent forwarding loop in the case when >>>>> customer would have backup connectivity to his sites or = connectivity >>>>> via different VPN provider yet routers in his site only partially >>>>> understand the STALE community and only partially follow the >>>>> forwarding rules ? >>>>> >>>>> In general as the rule is about mandating some particular order of >>>>> path forwarding selection what is the mechanism in distributed >>>>> systems like today's routing to be able to achieve any assurance >> that >>>>> such rule is active and enforced across _all_ routers behind EBGP >>>>> PE-CE L3VPN boundaries in customer sites ? >>>>> >>>>> Best regards, R. >>>>> >>>>> >>>>> -------- Original Message -------- Subject: [Idr] >>>>> draft-uttaro-idr-bgp-persistence-00 Date: Sat, 22 Oct 2011 = 00:23:55 >>>>> +0200 From: Robert Raszuk Reply-To: >>>>> robert@raszuk.net To: idr@ietf.org List >>>>> >>>>> Hi, >>>>> >>>>> I have read the draft and have one question and one observation. >>>>> >>>>> Question: >>>>> >>>>> What is the point of defining DO_NOT_PERSIST community ? In other >>>>> words why not having PERSIST community set would not mean the same >> as >>>>> having path marked with DO_NOT_PERSIST. >>>>> >>>>> Observation: >>>>> >>>>> I found the below statement in section 4.2: >>>>> >>>>> o Forwarding must ensure that the Next Hop to a "stale" route is >>>>> viable. >>>>> >>>>> Of course I agree. But since we stating obvious in the forwarding >>>>> section I think it would be good to explicitly also state this in >>>>> the best path selection that next hop to STALE best path must be >>>>> valid. >>>>> >>>>> However sessions especially those between loopbacks do not go down >>>>> for no reason. Most likely there is network problem which may have >>>>> caused those sessions to go down. It is therefor likely that LDP >>>>> session went also down between any of the LSRs in the data path = and >>>>> that in spite of having the paths in BGP and next hops in IGP the >> LSP >>>>> required for both quoted L2/L3VPN applications is broken. That may >>>>> particularly happen when network chooses to use independent = control >>>>> mode for label allocation. >>>>> >>>>> I would suggest to at least add the recommendation statement to = the >>>>> document that during best path selection especially for stale = paths >>>>> a validity of required forwarding paradigm to next hop of stale >>>>> paths should be verified. >>>>> >>>>> For example using techniques as described in: >>>>> draft-ietf-idr-bgp-bestpath-selection-criteria >>>>> >>>>> Best regards, R. >>>>> > From robert@raszuk.net Wed Nov 2 10:06:44 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A5C11E80AE for ; Wed, 2 Nov 2011 10:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eR-4Pa3uYHG for ; Wed, 2 Nov 2011 10:06:43 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id 7450811E8114 for ; Wed, 2 Nov 2011 10:06:43 -0700 (PDT) Received: (qmail 11293 invoked by uid 399); 2 Nov 2011 17:06:42 -0000 Received: from unknown (HELO ?192.168.1.52?) (83.31.220.67) by mail37.opentransfer.com with SMTP; 2 Nov 2011 17:06:42 -0000 Message-ID: <4EB17893.1060706@raszuk.net> Date: Wed, 02 Nov 2011 18:06:27 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: bruno.decraene@orange.com References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net> <4EA84254.9000400@raszuk.net> <4EB14BDD.7040802@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org, ju1738@att.com Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 17:06:44 -0000 > Sure. But given the small number of RR boxes, and the high requirements > on these boxes, it's harder to justify a two or three vendor sourcing. I would think just the very opposite. Small number of RRs and their high requirements IMHO fully justify more then one vendor sourcing. Of course fun starts where it is hard to find such diverse RRs with all required feature sets. Those concerned about such issues are looking actively in solving the problem fundamentally at it's roots and not cover it with yet another curtain. Cheers, R. From robert@raszuk.net Wed Nov 2 10:16:08 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D92611E8126 for ; Wed, 2 Nov 2011 10:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zeJ4Pf5rlE6 for ; Wed, 2 Nov 2011 10:16:08 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id 4A77A11E8111 for ; Wed, 2 Nov 2011 10:16:07 -0700 (PDT) Received: (qmail 15149 invoked by uid 399); 2 Nov 2011 17:16:01 -0000 Received: from unknown (HELO ?192.168.1.52?) (83.31.220.67) by mail37.opentransfer.com with SMTP; 2 Nov 2011 17:16:01 -0000 Message-ID: <4EB17AC2.9030605@raszuk.net> Date: Wed, 02 Nov 2011 18:15:46 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: bruno.decraene@orange.com References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net><4EA84254.9000400@raszuk.net> <4EA8A91C.4090305@cisco.com> <4EB157DA.8010902@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 17:16:08 -0000 Bruno, > No. Interaction between GR and persistence is currently not described > in this version. It will be in the next version. In short, if GR& > persistence were enabled both on a BGP session, GR would first run. > Then if GR does not succeed, persistence would come into play. Ohh this is news. How do you define GR success ? Do you mean that persistance would work till GR timer expires then if session did not come up re-advertise all routes as stale as opposed to withdraw them ? > No. If GR success, there would be no churn. Otherwise, single churn Sorry ... double. When session comes up and such session was there I assume for a reason so it is likely to come up you need to wipe out the STALE color. Btw ... I assume next version will also include discussion that SHUT community is mutually exclusive with persistence draft - correct ? ;) > Indeed, no capability negotiation is required. We only need EOR. In > v00, it has been assumed that EOR is now a standard behavior. > Otherwise we could explicitly signal this using the GR capability. As much as we all want to have it as standard behaviour it is not yet so mentioning about it will not hurt. > " o The Receiving Speaker MUST replace the stale routes by the > routing updates received from the peer. Once the End-of-RIB marker > for an address family is received from the peer, it MUST immediately > remove any paths from the peer that are still marked as stale for > that address family." And that is precisely what GR spec recommends. This is also why I started by saying that persistence draft copies existing control plane functionality from GR RFC. Best, R. From bruno.decraene@orange.com Wed Nov 2 10:22:08 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE5C11E811C for ; Wed, 2 Nov 2011 10:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyjSFxRw6KoP for ; Wed, 2 Nov 2011 10:22:07 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 58A2F11E8111 for ; Wed, 2 Nov 2011 10:22:07 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DC02C9B0003; Wed, 2 Nov 2011 18:23:08 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id D33018F0001; Wed, 2 Nov 2011 18:23:08 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Nov 2011 18:22:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Nov 2011 18:22:05 +0100 Message-ID: In-Reply-To: <4EB17893.1060706@raszuk.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-00 Thread-Index: AcyZgd5Z8CiW9mTGQTSshB0NSEvAUgAAMOCA References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net> <4EA84254.9000400@raszuk.net> <4EB14BDD.7040802@raszuk.net> <4EB17893.1060706@raszuk.net> From: To: X-OriginalArrivalTime: 02 Nov 2011 17:22:07.0084 (UTC) FILETIME=[F23E5AC0:01CC9983] Cc: idr@ietf.org, ju1738@att.com Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 17:22:08 -0000 >> Sure. But given the small number of RR boxes, and the high requirements >> on these boxes, it's harder to justify a two or three vendor sourcing. > >I would think just the very opposite. Small number of RRs and their high >requirements IMHO fully justify more then one vendor sourcing. Somehow we disagree on this.=20 Regarding the small number of RR, if you need 10 RR, it's hard to go to the buying, testing, integration and ops teams asking for a new vendor for 5 only boxes. Regarding dual sourcing, to keep redundancy, you would need to restrict yourself to the smaller intersection of features and performance. This can be limiting. >Of course fun starts where it is hard to find such diverse RRs with all >required feature sets. My point. Both features and scale. > Those concerned about such issues are looking >actively in solving the problem fundamentally at it's roots and not >cover it with yet another curtain. Dual sourcing helps but does not guaranty that both RR will never fail. You said it yourself. So this does not solve the fundamental problem. However, again, given the low probability of double failure, it's harder to justify work on this. >Cheers, >R. From robert@raszuk.net Wed Nov 2 10:27:08 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D63621F9FCA for ; Wed, 2 Nov 2011 10:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xu7shjziLVMC for ; Wed, 2 Nov 2011 10:27:07 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id 8896D21F9FDE for ; Wed, 2 Nov 2011 10:27:07 -0700 (PDT) Received: (qmail 19647 invoked by uid 399); 2 Nov 2011 17:27:06 -0000 Received: from unknown (HELO ?192.168.1.52?) (83.31.220.67) by mail37.opentransfer.com with SMTP; 2 Nov 2011 17:27:06 -0000 Message-ID: <4EB17D5C.30509@raszuk.net> Date: Wed, 02 Nov 2011 18:26:52 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: bruno.decraene@orange.com References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net> <4EA84254.9000400@raszuk.net> <4EB14BDD.7040802@raszuk.net> <4EB17893.1060706@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org, ju1738@att.com Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 17:27:08 -0000 >> Those concerned about such issues are looking >> actively in solving the problem fundamentally at it's roots and not >> cover it with yet another curtain. > > Dual sourcing helps but does not guaranty that both RR will never fail. > You said it yourself. So this does not solve the fundamental problem. When I mentioned to solve the fundamental problem I did not mean to continue to use current model in particular to continue to use RRs at all. Btw this is topic not for this thread ;) I will start new one perhaps in few weeks to discuss it. Cheers, R. From ju1738@att.com Wed Nov 2 10:53:37 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BAC511E814C for ; Wed, 2 Nov 2011 10:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.043 X-Spam-Level: X-Spam-Status: No, score=-106.043 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKFBsLg+0XGw for ; Wed, 2 Nov 2011 10:53:33 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id CD7A411E8147 for ; Wed, 2 Nov 2011 10:53:32 -0700 (PDT) X-Env-Sender: ju1738@att.com X-Msg-Ref: server-12.tower-119.messagelabs.com!1320256409!47794857!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6413 invoked from network); 2 Nov 2011 17:53:30 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-12.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Nov 2011 17:53:30 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pA2HruMU030113; Wed, 2 Nov 2011 13:53:57 -0400 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (misout7msghub9c.itservices.sbc.com [144.151.223.82]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pA2HrsDs030068 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Nov 2011 13:53:54 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([169.254.1.231]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.01.0339.001; Wed, 2 Nov 2011 13:53:26 -0400 From: "UTTARO, JAMES" To: "'bruno.decraene@orange.com'" , "robert@raszuk.net" Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-00 Thread-Index: AQHMkEAnLP0iAkRlVkChUYWtkZqOMQAAMOCAlZntKQA= Date: Wed, 2 Nov 2011 17:53:26 +0000 Message-ID: References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net> <4EA84254.9000400@raszuk.net> <4EB14BDD.7040802@raszuk.net> <4EB17893.1060706@raszuk.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.4.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 17:53:37 -0000 I believe that the what is being missed in this discussion is impact... Yes= Dual RR failures are rare but when they happen it is analogous to an aster= oid killer, you know, front page NYT etc.. So although it is a low frequenc= y event the impact is beyond the pale.. Without getting into specifics I kn= ow this has happened. It needs to be defended against in a way that does no= t rely on probabilities of different RRs from different vendors on differen= t platforms.. All of that may lessen the chance ( maybe ) but it comes with= a huge testing/certification/inter-operability etc... challenge and does n= ot guarantee protection.=20 Thanks, Jim Uttaro -----Original Message----- From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com]=20 Sent: Wednesday, November 02, 2011 1:22 PM To: robert@raszuk.net Cc: idr@ietf.org; UTTARO, JAMES Subject: RE: [Idr] draft-uttaro-idr-bgp-persistence-00 >> Sure. But given the small number of RR boxes, and the high requirements >> on these boxes, it's harder to justify a two or three vendor sourcing. > >I would think just the very opposite. Small number of RRs and their high >requirements IMHO fully justify more then one vendor sourcing. Somehow we disagree on this.=20 Regarding the small number of RR, if you need 10 RR, it's hard to go to the buying, testing, integration and ops teams asking for a new vendor for 5 only boxes. Regarding dual sourcing, to keep redundancy, you would need to restrict yourself to the smaller intersection of features and performance. This can be limiting. >Of course fun starts where it is hard to find such diverse RRs with all >required feature sets. My point. Both features and scale. > Those concerned about such issues are looking >actively in solving the problem fundamentally at it's roots and not >cover it with yet another curtain. Dual sourcing helps but does not guaranty that both RR will never fail. You said it yourself. So this does not solve the fundamental problem. However, again, given the low probability of double failure, it's harder to justify work on this. >Cheers, >R. From jakob.heitz@ericsson.com Wed Nov 2 13:06:00 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B31CD1F0CBD for ; Wed, 2 Nov 2011 13:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[AWL=2.279, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32WDfdC4Tg6z for ; Wed, 2 Nov 2011 13:06:00 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 15ED11F0CA9 for ; Wed, 2 Nov 2011 13:06:00 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pA2K5ZTM024261; Wed, 2 Nov 2011 15:05:56 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.52]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 2 Nov 2011 16:05:46 -0400 From: Jakob Heitz To: Enke Chen , "UTTARO, JAMES" Date: Wed, 2 Nov 2011 16:05:45 -0400 Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-00: Security Considerations Thread-Index: AcyUQUvR0V1Lw/DcSim4lhtSjHsEKAFVyizg Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391A447FB381@EUSAACMS0701.eamcs.ericsson.se> References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net> <4EA84254.9000400@raszuk.net> <4EA8A91C.4090305@cisco.com> In-Reply-To: <4EA8A91C.4090305@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org List" , "robert@raszuk.net" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00: Security Considerations 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, 02 Nov 2011 20:06:00 -0000 On Wednesday, October 26, 2011 5:43 PM, Enke Chen <> wrote: > Hi, folks: >=20 > I have a hard time in understanding what new problems (beyond the GR) > the draft try to solve :-( Me too. The persisting routers will persistently send labeled packets into the core. If the intended destination really has disappeared, and restarted, what is the chance that such labeled packets interfere with other unrelated services, just because of labels being reused? Quote from 3.1 of the draft: The persist-timer should be set to a large value on the order of days to infinity. Customers rely on the separation between VPN's. The "P" means private. Anything that threatens that "P" should not be taken lightly. I'm starting to imagine my video stream intrespersed with dzzt, zzt from random packets being injected into it. How real is that? --=20 Jakob Heitz.= From ju1738@att.com Wed Nov 2 13:20:51 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4E6711E8159 for ; Wed, 2 Nov 2011 13:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.105 X-Spam-Level: X-Spam-Status: No, score=-106.105 tagged_above=-999 required=5 tests=[AWL=0.494, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DwLhebaLDn2 for ; Wed, 2 Nov 2011 13:20:51 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 0E26411E8122 for ; Wed, 2 Nov 2011 13:20:50 -0700 (PDT) X-Env-Sender: ju1738@att.com X-Msg-Ref: server-9.tower-119.messagelabs.com!1320265246!47902297!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6148 invoked from network); 2 Nov 2011 20:20:46 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-9.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Nov 2011 20:20:46 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pA2KLDdL025452; Wed, 2 Nov 2011 16:21:14 -0400 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pA2KL80v025345 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Nov 2011 16:21:08 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([169.254.1.231]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.01.0339.001; Wed, 2 Nov 2011 16:20:41 -0400 From: "UTTARO, JAMES" To: "'Jakob Heitz'" , Enke Chen Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-00: Security Considerations Thread-Index: AQHMmZzjYL6llAJn90+pSAwemYlI5Q== Date: Wed, 2 Nov 2011 20:20:40 +0000 Message-ID: References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net> <4EA84254.9000400@raszuk.net> <4EA8A91C.4090305@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21391A447FB381@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391A447FB381@EUSAACMS0701.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.4.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org List" , "robert@raszuk.net" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00: Security Considerations 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, 02 Nov 2011 20:20:52 -0000 Jakob, See the security section of the draft. Jim Uttaro -----Original Message----- From: Jakob Heitz [mailto:jakob.heitz@ericsson.com]=20 Sent: Wednesday, November 02, 2011 4:06 PM To: Enke Chen; UTTARO, JAMES Cc: idr@ietf.org List; robert@raszuk.net Subject: RE: [Idr] draft-uttaro-idr-bgp-persistence-00: Security Considerat= ions On Wednesday, October 26, 2011 5:43 PM, Enke Chen <> wrote: > Hi, folks: >=20 > I have a hard time in understanding what new problems (beyond the GR) > the draft try to solve :-( Me too. The persisting routers will persistently send labeled packets into the core. If the intended destination really has disappeared, and restarted, what is the chance that such labeled packets interfere with other unrelated services, just because of labels being reused? Quote from 3.1 of the draft: The persist-timer should be set to a large value on the order of days to infinity. Customers rely on the separation between VPN's. The "P" means private. Anything that threatens that "P" should not be taken lightly. I'm starting to imagine my video stream intrespersed with dzzt, zzt from random packets being injected into it. How real is that? --=20 Jakob Heitz. From jakob.heitz@ericsson.com Wed Nov 2 13:29:27 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6F2E1F0C9E for ; Wed, 2 Nov 2011 13:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.08 X-Spam-Level: X-Spam-Status: No, score=-5.08 tagged_above=-999 required=5 tests=[AWL=1.519, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhkYm8IMcwVa for ; Wed, 2 Nov 2011 13:29:27 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4D95F1F0C59 for ; Wed, 2 Nov 2011 13:29:27 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pA2KTOjY028796; Wed, 2 Nov 2011 15:29:25 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.52]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 2 Nov 2011 16:29:19 -0400 From: Jakob Heitz To: "UTTARO, JAMES" , Enke Chen Date: Wed, 2 Nov 2011 16:29:18 -0400 Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-00: Security Considerations Thread-Index: AQHMmZzjYL6llAJn90+pSAwemYlI5ZWaBu/w Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391A447FB3A4@EUSAACMS0701.eamcs.ericsson.se> References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net> <4EA84254.9000400@raszuk.net> <4EA8A91C.4090305@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21391A447FB381@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org List" , "robert@raszuk.net" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00: Security Considerations 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, 02 Nov 2011 20:29:28 -0000 On Wednesday, November 02, 2011 1:21 PM, UTTARO, JAMES wrote: > Jakob, >=20 > See the security section of the draft. I did, but it doesn't answer my questions. It diverts the reader's attention with talk of malicious disturbance. Accidental disturbance seems much more real to me. The chance of such an accidental disturbance seems to me to be high enough to sink this proposal cold. However, I don't actually know. Am I scared of ghosts or is it real? Some credible research results might relieve my anxiety. >=20 > Jim Uttaro >=20 > -----Original Message----- > From: Jakob Heitz [mailto:jakob.heitz@ericsson.com] > Sent: Wednesday, November 02, 2011 4:06 PM > To: Enke Chen; UTTARO, JAMES > Cc: idr@ietf.org List; robert@raszuk.net > Subject: RE: [Idr] draft-uttaro-idr-bgp-persistence-00: Security > Considerations=20 >=20 > On Wednesday, October 26, 2011 5:43 PM, Enke Chen <> wrote: >=20 >> Hi, folks: >>=20 >> I have a hard time in understanding what new problems (beyond the GR) >> the draft try to solve :-( >=20 > Me too. >=20 > The persisting routers will persistently send labeled packets > into the core. If the intended destination really has disappeared, > and restarted, what is the chance that such labeled packets > interfere with other unrelated services, just because of labels > being reused? >=20 > Quote from 3.1 of the draft: > The persist-timer > should be set to a large value on the order of days to infinity. >=20 > Customers rely on the separation between VPN's. The "P" means private. > Anything that threatens that "P" should not be taken lightly. >=20 > I'm starting to imagine my video stream intrespersed with dzzt, zzt > from random packets being injected into it. How real is that? From robert@raszuk.net Wed Nov 2 15:35:05 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB3A11E80F1 for ; Wed, 2 Nov 2011 15:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHGZY-lO60hA for ; Wed, 2 Nov 2011 15:35:05 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id AFAB111E80A5 for ; Wed, 2 Nov 2011 15:35:04 -0700 (PDT) Received: (qmail 19909 invoked by uid 399); 2 Nov 2011 22:35:02 -0000 Received: from unknown (HELO ?216.69.73.170?) (216.69.73.170) by mail37.opentransfer.com with SMTP; 2 Nov 2011 22:35:02 -0000 Message-ID: <4EB1C596.5030306@raszuk.net> Date: Wed, 02 Nov 2011 23:35:02 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Jakob Heitz References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net> <4EA84254.9000400@raszuk.net> <4EA8A91C.4090305@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21391A447FB381@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391A447FB381@EUSAACMS0701.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" , "UTTARO, JAMES" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00: Security Considerations X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 22:35:05 -0000 Hi Jakob, Let me try to understand the issue you are describing a bit better. If we have a below scenario: / PE2 PE1 -- RR \ PE3 When PE2 disappears RR will re-advertise his routes as persistent to PE1 with some labels - for simplicity let's assume those are L3VPN labels. There are two options ... * PE2 went down for good - RR by advertising persistent routes may at most cause to blackhole the traffic - that is why I started by recommending a MUST for next hop reachability * PE2 restarted - here I assume RR would withdraw previous STALE routes by both implicit withdraw and explicit withdraw - when new session comes up between RR and PE2. RR knows the same rtr_id/peer_ip (session got reestablished). I really can not imagine otherwise regardless of persistence timer value setting. Labels are of local significance. They alone mean nothing without the next hop. So I fail to see the case you describe or for that matter described by security section that even transiently labels advertised with BGP NLRIs are going to cause harm or inter-VPN disturbance. En-light me pls ! I want to see the ghost ;-) Cheers, R. > On Wednesday, October 26, 2011 5:43 PM, Enke Chen<> wrote: > >> Hi, folks: >> >> I have a hard time in understanding what new problems (beyond the GR) >> the draft try to solve :-( > > Me too. > > The persisting routers will persistently send labeled packets > into the core. If the intended destination really has disappeared, > and restarted, what is the chance that such labeled packets > interfere with other unrelated services, just because of labels > being reused? > > Quote from 3.1 of the draft: > The persist-timer > should be set to a large value on the order of days to infinity. > > Customers rely on the separation between VPN's. The "P" means private. > Anything that threatens that "P" should not be taken lightly. > > I'm starting to imagine my video stream intrespersed with dzzt, zzt > from random packets being injected into it. How real is that? > From erosen@cisco.com Wed Nov 2 19:49:45 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E3F11E8081 for ; Wed, 2 Nov 2011 19:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xU-hHqdeN-92 for ; Wed, 2 Nov 2011 19:49:44 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id CE2D011E8096 for ; Wed, 2 Nov 2011 19:49:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=erosen@cisco.com; l=1678; q=dns/txt; s=iport; t=1320288584; x=1321498184; h=to:cc:subject:in-reply-to:reply-to:date:message-id:from; bh=TSHumu2ISXb4dllvKtdVF4HQoK9LFCT3v65Yg0B4aL8=; b=VCp4952ift9zI/ynuqvWY/gO/VJZnl6O8I6YZNCw4diOsRGv4UuApnzM OzcwJHpxj3WJTTFZYLtpaK0ckM6LwgbEWa8zglT6Bj/huqO/sYvBudBuY H92iai0TgbTVUqYHf+S+AYsQc7NpAJ9VMBeDaUHwJcbpT660nws+HJS1J Q=; X-IronPort-AV: E=Sophos;i="4.69,447,1315180800"; d="scan'208";a="12054047" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 03 Nov 2011 02:49:42 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pA32neRS014891; Thu, 3 Nov 2011 02:49:40 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id pA32ndgB014154; Wed, 2 Nov 2011 22:49:39 -0400 To: robert@raszuk.net In-reply-to: Your message of Wed, 02 Nov 2011 23:35:02 +0100. <4EB1C596.5030306@raszuk.net> Date: Wed, 02 Nov 2011 22:49:39 -0400 Message-ID: <14153.1320288579@erosen-linux> From: Eric Rosen Cc: "idr@ietf.org List" , "UTTARO, JAMES" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00: Security Considerations X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 02:49:45 -0000 > If we have a below scenario: > > / PE2 > PE1 -- RR > \ PE3 > When PE2 disappears RR will re-advertise his routes as persistent to PE1 > with some labels - for simplicity let's assume those are L3VPN labels. In the case being discussed (I think), the RR is down at the time PE2 disappears, but PE1 is still using the routes previously distributed to it by the RR. > There are two options ... > * PE2 went down for good - RR by advertising persistent routes may at > most cause to blackhole the traffic - that is why I started by > recommending a MUST for next hop reachability > * PE2 restarted - here I assume RR would withdraw previous STALE routes > by both implicit withdraw and explicit withdraw The RR can't withdraw any routes because it is down. If PE1 happens to have noticed that PE2 blinked out, it may be wise for PE1 to invalidate the routes for which PE2 is the next hop. If PE1 did not notice that PE2 blinked out, it will continue to make use PE2's old VPN-IP routes. Unfortunately, all these routes will now have incorrect labels, and packets from one VPN may get forwarded by PE2 to another VPN. As far as I can tell, until the RR comes back up, there is no assurance that PE1 will notice PE2's restart, so random cross-connection of VPNs is certainly possible. But it's not obvious that random cross-connections of this sort are any worse than a complete loss of service. While datagrams from one VPN might get sprayed into the other, it is hard to see how a TCP connection between the two VPNs could be set up or maintained, since there is not going to be a working reverse path. From jakob.heitz@ericsson.com Wed Nov 2 20:51:57 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99DC511E8098 for ; Wed, 2 Nov 2011 20:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.16 X-Spam-Level: X-Spam-Status: No, score=-5.16 tagged_above=-999 required=5 tests=[AWL=0.839, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5RPr-GxbY0d for ; Wed, 2 Nov 2011 20:51:57 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 11E7811E8080 for ; Wed, 2 Nov 2011 20:51:57 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id pA33pMmI030372 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Nov 2011 22:51:22 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.52]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 2 Nov 2011 23:51:21 -0400 From: Jakob Heitz To: "erosen@cisco.com" , "robert@raszuk.net" Date: Wed, 2 Nov 2011 23:51:19 -0400 Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-00: Security Considerations Thread-Index: AcyZ0z95EN6aLCCQQUunxZ2ZpCErUQABBXlg Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391A447FB512@EUSAACMS0701.eamcs.ericsson.se> References: Your message of Wed, 02 Nov 2011 23:35:02 +0100. <4EB1C596.5030306@raszuk.net> <14153.1320288579@erosen-linux> In-Reply-To: <14153.1320288579@erosen-linux> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org List" , "UTTARO, JAMES" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00: Security Considerations 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, 03 Nov 2011 03:51:57 -0000 On Wednesday, November 02, 2011 7:50 PM, Eric Rosen wrote: >> If we have a below scenario: >>=20 >> / PE2 >> PE1 -- RR >> \ PE3 >=20 >> When PE2 disappears RR will re-advertise his routes as persistent to >> PE1 with some labels - for simplicity let's assume those are L3VPN >> labels.=20 >=20 > In the case being discussed (I think), the RR is down at the time PE2 > disappears, but PE1 is still using the routes previously distributed > to it=20 > by the RR. >=20 >> There are two options ... >=20 >> * PE2 went down for good - RR by advertising persistent routes may at >> most cause to blackhole the traffic - that is why I started by >> recommending a MUST for next hop reachability >=20 >> * PE2 restarted - here I assume RR would withdraw previous STALE >> routes by both implicit withdraw and explicit withdraw >=20 > The RR can't withdraw any routes because it is down. >=20 > If PE1 happens to have noticed that PE2 blinked out, it may be wise > for PE1=20 > to invalidate the routes for which PE2 is the next hop. If PE1 did > not=20 > notice that PE2 blinked out, it will continue to make use PE2's old > VPN-IP=20 > routes. Unfortunately, all these routes will now have incorrect > labels, and=20 > packets from one VPN may get forwarded by PE2 to another VPN. >=20 > As far as I can tell, until the RR comes back up, there is no > assurance that=20 > PE1 will notice PE2's restart, so random cross-connection of VPNs is > certainly possible. >=20 > But it's not obvious that random cross-connections of this sort are > any=20 > worse than a complete loss of service. While datagrams from one VPN > might=20 > get sprayed into the other, it is hard to see how a TCP connection > between=20 > the two VPNs could be set up or maintained, since there is not going > to be a=20 > working reverse path. I didn't think a stray packet could set up a TCP connection either. I was wondering if stray packets could cause disruptions of other kinds. Also, as a customer of a VPN service, I would not like the possibility of my packets being sprayed into other VPNs. --=20 Jakob Heitz.= From robert@raszuk.net Wed Nov 2 23:06:10 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF661F0C55 for ; Wed, 2 Nov 2011 23:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWfxwXoQR-3q for ; Wed, 2 Nov 2011 23:06:09 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id 1FA671F0C54 for ; Wed, 2 Nov 2011 23:06:08 -0700 (PDT) Received: (qmail 3202 invoked by uid 399); 3 Nov 2011 06:06:07 -0000 Received: from unknown (HELO ?192.168.1.57?) (178.42.163.36) by mail37.opentransfer.com with SMTP; 3 Nov 2011 06:06:07 -0000 Message-ID: <4EB22F4F.9080604@raszuk.net> Date: Thu, 03 Nov 2011 07:06:07 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: erosen@cisco.com References: <14153.1320288579@erosen-linux> In-Reply-To: <14153.1320288579@erosen-linux> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" , "UTTARO, JAMES" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00: Security Considerations 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, 03 Nov 2011 06:06:10 -0000 Eric, > If PE1 happens to have noticed that PE2 blinked out, it may be wise for PE1 > to invalidate the routes for which PE2 is the next hop. If PE1 did not > notice that PE2 blinked out, it will continue to make use PE2's old VPN-IP > routes. So when RR is down PE2's BGP process restarts while IGP not - PE1 has no chance to notice any next hop blink - hence till RR comes up and cleans up the mess pretty much network is in a bad state. How long RR will wait after coming up to get his previous IBGP peering reestablished before starting the cleanup ? Thx, R. >> If we have a below scenario: >> >> / PE2 >> PE1 -- RR >> \ PE3 > >> When PE2 disappears RR will re-advertise his routes as persistent to PE1 >> with some labels - for simplicity let's assume those are L3VPN labels. > > In the case being discussed (I think), the RR is down at the time PE2 > disappears, but PE1 is still using the routes previously distributed to it > by the RR. > >> There are two options ... > >> * PE2 went down for good - RR by advertising persistent routes may at >> most cause to blackhole the traffic - that is why I started by >> recommending a MUST for next hop reachability > >> * PE2 restarted - here I assume RR would withdraw previous STALE routes >> by both implicit withdraw and explicit withdraw > > The RR can't withdraw any routes because it is down. > > If PE1 happens to have noticed that PE2 blinked out, it may be wise for PE1 > to invalidate the routes for which PE2 is the next hop. If PE1 did not > notice that PE2 blinked out, it will continue to make use PE2's old VPN-IP > routes. Unfortunately, all these routes will now have incorrect labels, and > packets from one VPN may get forwarded by PE2 to another VPN. > > As far as I can tell, until the RR comes back up, there is no assurance that > PE1 will notice PE2's restart, so random cross-connection of VPNs is > certainly possible. > > But it's not obvious that random cross-connections of this sort are any > worse than a complete loss of service. While datagrams from one VPN might > get sprayed into the other, it is hard to see how a TCP connection between > the two VPNs could be set up or maintained, since there is not going to be a > working reverse path. > > > > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > From robert@raszuk.net Wed Nov 2 23:15:05 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFA61F0C81 for ; Wed, 2 Nov 2011 23:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5P32nFB1Rtk for ; Wed, 2 Nov 2011 23:15:04 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id 2E2691F0C78 for ; Wed, 2 Nov 2011 23:15:04 -0700 (PDT) Received: (qmail 6341 invoked by uid 399); 3 Nov 2011 06:15:03 -0000 Received: from unknown (HELO ?192.168.1.57?) (178.42.163.36) by mail37.opentransfer.com with SMTP; 3 Nov 2011 06:15:03 -0000 Message-ID: <4EB23167.1000307@raszuk.net> Date: Thu, 03 Nov 2011 07:15:03 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: erosen@cisco.com References: <14153.1320288579@erosen-linux> <4EB22F4F.9080604@raszuk.net> In-Reply-To: <4EB22F4F.9080604@raszuk.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" , "UTTARO, JAMES" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00: Security Considerations 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, 03 Nov 2011 06:15:05 -0000 Extending the question ... > How long RR will wait after coming up to get his previous IBGP > peering reestablished before starting the cleanup ? Actually RR can not do any cleanup if RR - PE2 never comes up can it ? It seems that PE1 will continue in this case to keep zombie paths PE2 via RR forever. The possible solution would be for PE1 to not only invalidate paths with "blinked" next hop, but also when previously lost session given paths were received over got reestablished. But I do not think draft mandates such behaviour. R. > Eric, > >> If PE1 happens to have noticed that PE2 blinked out, it may be wise >> for PE1 >> to invalidate the routes for which PE2 is the next hop. If PE1 did not >> notice that PE2 blinked out, it will continue to make use PE2's old >> VPN-IP >> routes. > > So when RR is down PE2's BGP process restarts while IGP not - PE1 has no > chance to notice any next hop blink - hence till RR comes up and cleans > up the mess pretty much network is in a bad state. > > How long RR will wait after coming up to get his previous IBGP peering > reestablished before starting the cleanup ? > > / PE2 > PE1 -- RR > \ PE3 > > Thx, > R. From bruno.decraene@orange.com Thu Nov 3 01:45:08 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63EB61F0C90 for ; Thu, 3 Nov 2011 01:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvho-rErrNx9 for ; Thu, 3 Nov 2011 01:45:08 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 9FBF91F0C70 for ; Thu, 3 Nov 2011 01:45:07 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C1AA38B80B5; Thu, 3 Nov 2011 09:46:27 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id B4DE48B801C; Thu, 3 Nov 2011 09:46:27 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Nov 2011 09:45:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Nov 2011 09:45:03 +0100 Message-ID: In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391A447FB381@EUSAACMS0701.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-00: Security Considerations Thread-Index: AcyUQUvR0V1Lw/DcSim4lhtSjHsEKAFVyizgABnyD6A= References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net><4EA84254.9000400@raszuk.net> <4EA8A91C.4090305@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21391A447FB381@EUSAACMS0701.eamcs.ericsson.se> From: To: X-OriginalArrivalTime: 03 Nov 2011 08:45:04.0924 (UTC) FILETIME=[E20225C0:01CC9A04] Cc: idr@ietf.org, ju1738@att.com, robert@raszuk.net Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00: Security Considerations 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, 03 Nov 2011 08:45:08 -0000 Jakob, >From: Jakob Heitz >Sent: Wednesday, November 02, 2011 9:06 PM > >On Wednesday, October 26, 2011 5:43 PM, Enke Chen <> wrote: > >> Hi, folks: >> >> I have a hard time in understanding what new problems (beyond the GR) >> the draft try to solve :-( > >Me too. > >The persisting routers will persistently send labeled packets >into the core. If the intended destination really has disappeared, If by "really has disappeared", you mean the egress PE (PE2 in Robert's picture, copied below) is down, then BGP routes whose BGP Next Hop are PE2 are invalidated (by all ingress PE and also by the persistent RR). No problem. If you actually mean that PE2 is alive but has lost its BGP session to both RR, then this is the case discussed in the security section of the draft. If you're not happy with it, please be more specific and say why (because " It diverts the reader's attention with talk of malicious disturbance." is not helping in addressing your original comment). / PE2 PE1 -- RR \ PE3 >and restarted, what is the chance that such labeled packets >interfere with other unrelated services, just because of labels >being reused? > >Quote from 3.1 of the draft: >The persist-timer > should be set to a large value on the order of days to infinity. > >Customers rely on the separation between VPN's. The "P" means private. >Anything that threatens that "P" should not be taken lightly. > >I'm starting to imagine my video stream intrespersed with dzzt, zzt >from random packets being injected into it. How real is that? > >-- >Jakob Heitz. >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From bruno.decraene@orange.com Thu Nov 3 01:45:14 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F28D71F0C93 for ; Thu, 3 Nov 2011 01:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lHijrua++08 for ; Thu, 3 Nov 2011 01:45:14 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id F01911F0C61 for ; Thu, 3 Nov 2011 01:45:13 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C8507B5801B; Thu, 3 Nov 2011 09:55:15 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id BFF06858002; Thu, 3 Nov 2011 09:55:15 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Nov 2011 09:45:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Nov 2011 09:45:11 +0100 Message-ID: In-Reply-To: <4EB22F4F.9080604@raszuk.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-00: SecurityConsiderations Thread-Index: AcyZ7rT0g5Xn7zPKS7iAJpGq6h/fqgAE6BEw References: <14153.1320288579@erosen-linux> <4EB22F4F.9080604@raszuk.net> From: To: , X-OriginalArrivalTime: 03 Nov 2011 08:45:12.0816 (UTC) FILETIME=[E6B65F00:01CC9A04] Cc: idr@ietf.org, ju1738@att.com Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00: SecurityConsiderations 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, 03 Nov 2011 08:45:15 -0000 Robert, >From: Robert Raszuk >Sent: Thursday, November 03, 2011 7:06 AM > >Eric, > >> If PE1 happens to have noticed that PE2 blinked out, it may be wise for PE1 >> to invalidate the routes for which PE2 is the next hop. If PE1 did not >> notice that PE2 blinked out, it will continue to make use PE2's old VPN-IP >> routes. > >So when RR is down PE2's BGP process restarts while IGP not - PE1 has no >chance to notice any next hop blink - hence till RR comes up and cleans >up the mess pretty much network is in a bad state. I've lost the kind of failures you are discussing. I don't recognize Jakob's case any more. Robert, are you talking about the following case: - RR1 is down - RR2 is down - PE2's BGP process restarts while IGP not. If yes, that seems a pretty specific case to me, but nonetheless, in such case, I believe the security section of the draft is applicable to this case. In short, at the time of the failure, forwarding (labels in FIB) are still correct. They will start becoming incorrect when PE2 change them (as ingress PE won't be aware of that change). If it's only a BGP restart on PE2 (everything else working fine) I assume PE2 should try to reuse the same label for the same route. Cf RFC 4781. If it's others events (e.g. customers route churn), I believe the security section of the draft precisely discuss this. If no, could you describe more precisely the case you are considering? >How long RR will wait after coming up to get his previous IBGP peering >reestablished before starting the cleanup ? > >Thx, >R. > > >>> If we have a below scenario: >>> >>> / PE2 >>> PE1 -- RR >>> \ PE3 >> >>> When PE2 disappears RR will re-advertise his routes as persistent to PE1 >>> with some labels - for simplicity let's assume those are L3VPN labels. >> >> In the case being discussed (I think), the RR is down at the time PE2 >> disappears, but PE1 is still using the routes previously distributed to it >> by the RR. >> >>> There are two options ... >> >>> * PE2 went down for good - RR by advertising persistent routes may at >>> most cause to blackhole the traffic - that is why I started by >>> recommending a MUST for next hop reachability >> >>> * PE2 restarted - here I assume RR would withdraw previous STALE routes >>> by both implicit withdraw and explicit withdraw >> >> The RR can't withdraw any routes because it is down. >> >> If PE1 happens to have noticed that PE2 blinked out, it may be wise for PE1 >> to invalidate the routes for which PE2 is the next hop. If PE1 did not >> notice that PE2 blinked out, it will continue to make use PE2's old VPN-IP >> routes. Unfortunately, all these routes will now have incorrect labels, and >> packets from one VPN may get forwarded by PE2 to another VPN. >> >> As far as I can tell, until the RR comes back up, there is no assurance that >> PE1 will notice PE2's restart, so random cross-connection of VPNs is >> certainly possible. >> >> But it's not obvious that random cross-connections of this sort are any >> worse than a complete loss of service. While datagrams from one VPN might >> get sprayed into the other, it is hard to see how a TCP connection between >> the two VPNs could be set up or maintained, since there is not going to be a >> working reverse path. >> >> >> >> >> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> >> > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From bruno.decraene@orange.com Thu Nov 3 01:49:52 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A47671F0C88 for ; Thu, 3 Nov 2011 01:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9QbuI154DP4 for ; Thu, 3 Nov 2011 01:49:51 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC3A1F0C61 for ; Thu, 3 Nov 2011 01:49:51 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 64FD8140070; Thu, 3 Nov 2011 09:49:48 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 5649214002F; Thu, 3 Nov 2011 09:49:48 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Nov 2011 09:49:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Nov 2011 09:49:47 +0100 Message-ID: In-Reply-To: <4EB17AC2.9030605@raszuk.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-00 Thread-Index: AcyZgxmcMUvnuAr7Q1y76L/gvpWZFQAgfN1A References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net><4EA84254.9000400@raszuk.net> <4EA8A91C.4090305@cisco.com> <4EB157DA.8010902@raszuk.net> <4EB17AC2.9030605@raszuk.net> From: To: X-OriginalArrivalTime: 03 Nov 2011 08:49:48.0241 (UTC) FILETIME=[8AE0E410:01CC9A05] Cc: idr@ietf.org Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 08:49:52 -0000 Robert, >From: Robert Raszuk [mailto:robert@raszuk.net] Sent: Wednesday, November 02, 2011 6:16 PM > >Bruno, > >> No. Interaction between GR and persistence is currently not described >> in this version. It will be in the next version. In short, if GR& >> persistence were enabled both on a BGP session, GR would first run. >> Then if GR does not succeed, persistence would come into play. > >Ohh this is news. This is a teaser. To save cycles, I suggest we wait for the draft to describe interaction with GR, before we discuss by emails. >How do you define GR success ? Do you mean that persistance would work >till GR timer expires then if session did not come up re-advertise all >routes as stale as opposed to withdraw them ? > >> No. If GR success, there would be no churn. Otherwise, single churn > >Sorry ... double. When session comes up and such session was there I >assume for a reason so it is likely to come up you need to wipe out the >STALE color. > >Btw ... I assume next version will also include discussion that SHUT >community is mutually exclusive with persistence draft - correct ? ;) > >> Indeed, no capability negotiation is required. We only need EOR. In >> v00, it has been assumed that EOR is now a standard behavior. >> Otherwise we could explicitly signal this using the GR capability. > >As much as we all want to have it as standard behaviour it is not yet so >mentioning about it will not hurt. > > >> " o The Receiving Speaker MUST replace the stale routes by the >> routing updates received from the peer. Once the End-of-RIB marker >> for an address family is received from the peer, it MUST immediately >> remove any paths from the peer that are still marked as stale for >> that address family." > >And that is precisely what GR spec recommends. This is also why I >started by saying that persistence draft copies existing control plane >functionality from GR RFC. > >Best, >R. > From robert@raszuk.net Thu Nov 3 05:37:35 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 782F811E8108 for ; Thu, 3 Nov 2011 05:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afxU9pJDUXbU for ; Thu, 3 Nov 2011 05:37:34 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id 695A511E80FC for ; Thu, 3 Nov 2011 05:37:34 -0700 (PDT) Received: (qmail 13015 invoked by uid 399); 3 Nov 2011 12:37:33 -0000 Received: from unknown (HELO ?192.168.1.52?) (83.31.228.14) by mail37.opentransfer.com with SMTP; 3 Nov 2011 12:37:33 -0000 Message-ID: <4EB28AFF.9060706@raszuk.net> Date: Thu, 03 Nov 2011 13:37:19 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: bruno.decraene@orange.com References: <14153.1320288579@erosen-linux> <4EB22F4F.9080604@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org, erosen@cisco.com, ju1738@att.com Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00: SecurityConsiderations 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, 03 Nov 2011 12:37:35 -0000 > If it's only > a BGP restart on PE2 (everything else working fine) I assume PE2 should > try to reuse the same label for the same route. I don't think so. Usually BGP asks for label block from label manager and allocates labels as seems fit. Only when a router would support RFC4781 which is BGP GR with labels that may not be the case. So are you saying that persistence draft now requires support of enabled RFC4781 as prerequisite ? Cheers, R. From bruno.decraene@orange.com Thu Nov 3 07:21:33 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B71C11E80C2 for ; Thu, 3 Nov 2011 07:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.992 X-Spam-Level: X-Spam-Status: No, score=-2.992 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJWKq4CdAWNX for ; Thu, 3 Nov 2011 07:21:32 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id A7B6711E80AF for ; Thu, 3 Nov 2011 07:21:32 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0C115858006; Thu, 3 Nov 2011 15:31:35 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 041D5858002; Thu, 3 Nov 2011 15:31:35 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Nov 2011 15:21:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Nov 2011 15:21:31 +0100 Message-ID: In-Reply-To: <4EB28AFF.9060706@raszuk.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-00:SecurityConsiderations Thread-Index: AcyaJWI3p7MjZwzHSGG1vj/N6DL0sAADfjMg References: <14153.1320288579@erosen-linux> <4EB22F4F.9080604@raszuk.net> <4EB28AFF.9060706@raszuk.net> From: To: X-OriginalArrivalTime: 03 Nov 2011 14:21:31.0933 (UTC) FILETIME=[E26744D0:01CC9A33] Cc: idr@ietf.org, erosen@cisco.com, ju1738@att.com Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00:SecurityConsiderations 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, 03 Nov 2011 14:21:33 -0000 >> If it's only >> a BGP restart on PE2 (everything else working fine) I assume PE2 should >> try to reuse the same label for the same route. > >I don't think so. Usually BGP asks for label block from label manager >and allocates labels as seems fit. > >Only when a router would support RFC4781 which is BGP GR with labels >that may not be the case. > >So are you saying that persistence draft now requires support of enabled >RFC4781 as prerequisite ? No, this is not required. But I have the impression that the possible use of RFC 4781 should be discussed as part of the security section of the draft. Cheers, Bruno >Cheers, >R. >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From erosen@cisco.com Thu Nov 3 09:06:38 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86661F0C9F for ; Thu, 3 Nov 2011 09:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUE1TOtUPqzh for ; Thu, 3 Nov 2011 09:06:38 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2651F0C81 for ; Thu, 3 Nov 2011 09:06:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=erosen@cisco.com; l=1477; q=dns/txt; s=iport; t=1320336398; x=1321545998; h=to:cc:subject:in-reply-to:reply-to:date:message-id:from; bh=CbZe5nrPQkYCPqIkgBaoP8tspgvHU2QX+8dnLHF6qkM=; b=L7jV6RqxQtyZxPW9lTesvf32TcfCCZh8aDbelcjuUcycE8kqfLG8zK2f 5iYVf2BsHjzAlpDNPkRMU0R0Uo3oTSuDhda45R/ioN5UGntaM1jSorB58 G/kEBPpL3ykgrVRK9xE5oeqMma/ZqFy9s4PoTZMxH9DqmFFvgq0bY24YT Y=; X-IronPort-AV: E=Sophos;i="4.69,450,1315180800"; d="scan'208";a="12167400" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 03 Nov 2011 16:06:38 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pA3G6bci007768; Thu, 3 Nov 2011 16:06:37 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id pA3G6aKB021346; Thu, 3 Nov 2011 12:06:36 -0400 To: Jakob Heitz In-reply-to: Your message of Wed, 02 Nov 2011 23:51:19 -0400. <7309FCBCAE981B43ABBE69B31C8D21391A447FB512@EUSAACMS0701.eamcs.ericsson.se> Date: Thu, 03 Nov 2011 12:06:36 -0400 Message-ID: <21345.1320336396@erosen-linux> From: Eric Rosen Cc: "idr@ietf.org List" , "erosen@cisco.com" , "UTTARO, JAMES" , "robert@raszuk.net" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00: Security Considerations X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 16:06:38 -0000 > I was wondering if stray packets could cause disruptions of other kinds. If PE2 connects to two sites of VPN1, then after PE2 restarts, proper VPN service between those two sites can be established without the aid of the RR. However, if those sites are now getting stray packets from VPN2 (via PE1), it does seem possible that these packets will disrupt service in VPN1. In such a case, the "persistence" strategy disrupts a service that would otherwise have been fine. This may or may not be deemed acceptable by a SP, but probably should be discussed in the draft. > as a customer of a VPN service, I would not like the possibility of my > packets being sprayed into other VPNs. This is the issue that the Security Considerations attempts to address by pointing out that there is no way to cause this spraying maliciously, and hence no way for someone to actually exploit the situation. The assumption is that a bit of accidental spraying is not actually going to result in damages, and is unlikely to even be noticed. Well, it is unlikely to be noticed unless the customer does a traceroute, and the ICMP error messages somehow make it back to the customer (via the Internet, say). Whether damages will result may depend on whether someone with poor ethics just happens to be running a LAN analyzer at an opportune moment, and just happens to see a packet from the other VPN that just happens to have some useful information in it. From skh@ndzh.com Tue Nov 8 08:50:01 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D44011E8081 for ; Tue, 8 Nov 2011 08:50:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.019 X-Spam-Level: X-Spam-Status: No, score=0.019 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fe2zZ98Xc5AA for ; Tue, 8 Nov 2011 08:50:00 -0800 (PST) Received: from hickoryhill-consulting.com (63-208-161-201.digitalrealm.net [63.208.161.201]) by ietfa.amsl.com (Postfix) with ESMTP id 2766A21F8BEE for ; Tue, 8 Nov 2011 08:50:00 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=63.133.138.150; Received: from SKHPERSONALLT (unverified [63.133.138.150]) by hickoryhill-consulting.com (SurgeMail 5.2a) with ESMTP id 2821824-1945496 for multiple; Tue, 08 Nov 2011 11:49:47 -0500 From: "Susan Hares" To: "'IETF IDR'" Date: Tue, 8 Nov 2011 11:49:53 -0500 Message-ID: <002301cc9e36$70d4ab30$527e0190$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0024_01CC9E0C.87FEA330" X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-us Thread-index: AcyeNnB3FlK70418R+Wlf2azZr+jVg== X-Authenticated-User: skh@ndzh.com Cc: idr-chairs@tools.ietf.org Subject: [Idr] draft-ietf-deprecate-as-sets will be released as a BCP 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, 08 Nov 2011 16:50:01 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0024_01CC9E0C.87FEA330 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit During the IESG processing, the draft-ietf-deprecate-as-sets turned into a BCP. Please look at the http://datatracker.ietf.org/doc/draft-ietf-idr-deprecate-as-sets. Danny McPherson noted that this was different than the IDR discussion, and had some concerns over the language. Perhaps, as the chairs we should have foreseen this possibility. However, the IESG language appears to the chairs to conform to RFC2119. Note that two of "should" are in small type and therefore not related to the SHOULD from RFC2119. The chairs are planning to accept the IESG review and changes. This is a last call for comment on these plans. Please comment on your concerns on the mail list by 11/15 or at the IDR meeting in Taipei. Sue and John ------=_NextPart_000_0024_01CC9E0C.87FEA330 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

During the IESG = processing, the draft-ietf-deprecate-as-sets turned into a BCP. =

Please look at the = http://datatracker.ietf.org/doc/draft-ietf-idr-deprecate-as-sets. =

 

Danny McPherson = noted that this was different than the IDR discussion, and had some = concerns over the language.

 

Perhaps, as the = chairs we should have foreseen this possibility. However, the IESG = language appears to the chairs to conform to RFC2119.  Note that = two of “should” are in small type and therefore not related = to the SHOULD from RFC2119.

 

The chairs are = planning to accept the IESG review and changes. This is a last call for = comment on these plans.

Please comment on = your concerns on the mail list by 11/15 or at the IDR meeting in Taipei. =

 

Sue and John =

 

------=_NextPart_000_0024_01CC9E0C.87FEA330-- From jgs@juniper.net Tue Nov 8 09:06:36 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 910F121F84C2 for ; Tue, 8 Nov 2011 09:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.529 X-Spam-Level: X-Spam-Status: No, score=-6.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PX59Jup1IAp for ; Tue, 8 Nov 2011 09:06:36 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id F406121F847F for ; Tue, 8 Nov 2011 09:06:34 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Tue, 08 Nov 2011 09:06:35 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 8 Nov 2011 09:03:11 -0800 From: John Scudder To: "idr@ietf.org List" Date: Tue, 8 Nov 2011 09:03:16 -0800 Thread-Topic: IDR agenda posted; call for note-takers Thread-Index: AcyeOEtYLp+ItIW9Ruyp0MfgJHi7Ew== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Idr] IDR agenda posted; call for note-takers 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, 08 Nov 2011 17:06:36 -0000 http://www.ietf.org/proceedings/82/agenda/idr.txt Please let the chairs know ASAP if anything is missing. I'll take this opportunity to remind presenters to get us your slides as so= on as you can and in any event, no later than 24 hours prior to the meeting= . =20 Finally, if you would be willing to take notes for either all or part of th= e meeting, please let us know. We had a number of volunteers last time and= that worked out well. We will also want someone to monitor the Jabber roo= m and relay questions. Thanks! --John= From stbryant@cisco.com Tue Nov 8 10:25:08 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE19621F8B50; Tue, 8 Nov 2011 10:25:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.406 X-Spam-Level: X-Spam-Status: No, score=-109.406 tagged_above=-999 required=5 tests=[AWL=1.193, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPztWQdOzRui; Tue, 8 Nov 2011 10:25:08 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9854D21F8505; Tue, 8 Nov 2011 10:24:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=3404; q=dns/txt; s=iport; t=1320776688; x=1321986288; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=VvX08JOZE+LFiIiFUmUtX8OMlGsthLUNEcjjf8RRRAw=; b=dEeUwQOalonDyt/vU/nybH8u4RDdyZoFJcm/2Lh1IEc9yIaSEbVmgbxB gQr2nPA3rC7R7Ur9x0JtYJ35QWYTplunL5k/PqAvDqe7ndMMr48ccpCXR VcwNsi51Rl/VwLUPdSU9NMxR9vR/Lzv1N5dFqfvSPQ+ZG7nLOE9WlNUmp I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am8FAF9zuU6Q/khM/2dsb2JhbABEqHuBJoEFgXIBAQEEAQEBDwECASI2CgEQCxgJFgQLCQMCAQIBFTAGDQEFAgEBEA6HaJhJAYMuDwGbTYktBJQhiHOIew X-IronPort-AV: E=Sophos;i="4.69,477,1315180800"; d="scan'208";a="59440577" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 08 Nov 2011 18:24:47 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pA8IODOh000515; Tue, 8 Nov 2011 18:24:14 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id pA8IOC5U011155; Tue, 8 Nov 2011 18:24:12 GMT Message-ID: <4EB973CC.8090006@cisco.com> Date: Tue, 08 Nov 2011 18:24:12 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Danny McPherson References: <20111010160636.16168.55257.idtracker@ietfa.amsl.com> <6D402923-AA10-4EA6-96DC-D88D8E935041@tcb.net> In-Reply-To: <6D402923-AA10-4EA6-96DC-D88D8E935041@tcb.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr mailing list , idr chair , The IESG , RFC Editor Subject: Re: [Idr] Protocol Action: 'Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP' to BCP (draft-ietf-idr-deprecate-as-sets-06.txt) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 18:25:08 -0000 Catching up on some older email It seems that there was an error in the last call notice, which was my fault. The text of the draft that was last called (version 5) was noted as BCP in its metadata, but the calling notice still listed it as informational. The request to change from informational to BCP follows a number of discussions in the IESG concerning what type of documents should be BCP vs which should be informational. In this case as it was advising the community of what we now thought was a good practice BCP seemed more appropriate. The document is still in the RFC editor's queue so if there is concern in the WG that the status is inappropriate I can pull it from the queue and bring it back WG/IETF LC. - Stewart On 10/10/2011 19:45, Danny McPherson wrote: > Can someone clue me in as to when the status of this changed > from Informational to BCP, in particular since this occurred > after the IETF last call said intended publication was > Informational? > > Also, what the implication of this might be on updating RFC 5065, > RFC 4271, etc.., as it "recommends against" standardized protocol > elements and doesn't contain RFC 2119 language. The IESG comments > discuss this as well, and I brought it up on the mailing list quite > a while ago when asking about expressly about intended status. > > In general, I don't have a problem with this being BCP if the wording > is cleaned up, but it certainly was not posited as BCP in WG or IETF > last call or discussed in the WG to that effect with any response. > > -danny > > > On Oct 10, 2011, at 12:06 PM, The IESG wrote: > >> The IESG has approved the following document: >> - 'Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP' >> (draft-ietf-idr-deprecate-as-sets-06.txt) as a BCP >> >> This document is the product of the Inter-Domain Routing Working Group. >> >> The IESG contact persons are Stewart Bryant and Adrian Farrel. >> >> A URL of this Internet Draft is: >> http://datatracker.ietf.org/doc/draft-ietf-idr-deprecate-as-sets/ >> >> >> >> >> Technical Summary >> >> This document provides advice to operators. It deprecates >> the use of the AS_SET and AS_CONFED_SET types of >> the AS_PATH in BGPv4. This is done to simplify the >> design and implementation of the BGP protocol and to make >> the semantics of the originator of a route more clear. >> >> Working Group Summary >> >> This document was adopted as a WG item on >> Oct 25th, 2010. There was an initial WGLC >> that concluded on April 13th, 2010. Comments >> from the initial WGLC were integrated and a >> second WGLC held, which concluded on May17, 2011. >> >> Document Quality >> >> This note provides advice to operators proposing that >> they cease using a current BGP protocol feature. >> >> Personnel >> >> John Scudder (jgs@juniper.net) is the document shepherd. >> Stewart Bryant (stbryant@cisco.com) is the responsible AD. >> >> RFC Editor Note >> >> There is no RFC2119 language used in the draft. >> >> Please remove section 2 - the RFC2119 section and the >> RFC2119 reference. >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From jgs@juniper.net Wed Nov 9 09:03:22 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 638BD21F8C84 for ; Wed, 9 Nov 2011 09:03:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.837 X-Spam-Level: X-Spam-Status: No, score=-5.837 tagged_above=-999 required=5 tests=[AWL=-0.635, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-PJPg1YCpTc for ; Wed, 9 Nov 2011 09:03:18 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id B578321F8C70 for ; Wed, 9 Nov 2011 09:03:17 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTrqyTnK27I4OdG3KbJsd45FLoZ2kJsHa@postini.com; Wed, 09 Nov 2011 09:03:17 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 9 Nov 2011 09:02:57 -0800 Received: from [172.19.168.4] ([172.19.168.4]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id pA9H2qh03467 for ; Wed, 9 Nov 2011 09:02:54 -0800 (PST) (envelope-from jgs@juniper.net) References: <4EBA594C.1060406@levkowetz.com> From: "John G. Scudder" Content-Type: multipart/alternative; boundary="Apple-Mail-6EAE8E53-6FD4-44F7-9929-2B9D7C10E86F" X-Mailer: iPhone Mail (9A334) Message-ID: Date: Wed, 9 Nov 2011 09:02:46 -0800 To: "idr@ietf.org" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (1.0) Subject: [Idr] Fwd: Etherpad for collaborative note-taking 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, 09 Nov 2011 17:03:22 -0000 --Apple-Mail-6EAE8E53-6FD4-44F7-9929-2B9D7C10E86F Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Further to my call for note-takers, feel free to experiment with this. --John Begin forwarded message: > From: Henrik Levkowetz > Date: November 9, 2011 2:43:24 AM PST > To: WG Chairs > Subject: Etherpad for collaborative note-taking > > Hi, > > Acting on a recent suggestion from Peter Saint-Andre (on ietf@ietf.org), > I've now set up an instance of Etherpad Lite (http://etherpad.org/) on > one of the tools servers, and used it to make a collaborative notes > document available for all WGs with a posted agenda for IETF-82. > > You'll find it both linked in and embedded in the minutes page for your WG > on tools.ietf.org; for an example see http://tools.ietf.org/wg/clue/minutes > > The note documents will be visible on the minutes page until you submit > official minutes for the meeting, at which time they will be replaced > by the minutes. The etherpad documents will still be accessible directly > at the etherpad URL for some time after the meeting, but will be archived > and replaced by new empty documents before the next meeting. > > Comments and suggestions are welcome! > > > Best regards, > > Henrik --Apple-Mail-6EAE8E53-6FD4-44F7-9929-2B9D7C10E86F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Further to my call for not= e-takers, feel free to experiment with this. 

--John
<= br>Begin forwarded message:

From:= Henrik Levkowetz <henrik@lev= kowetz.com>
Date: November 9, 2011 2:43:24 AM PST
To:= WG Chairs <wgchairs@ietf.org>
Subject: Etherpad for collaborative note-taking
Hi,

Acting on a recent suggestion from Peter Saint= -Andre (on ietf@ietf.org),
I've now set up an instance of Etherpad Lite (http://etherpad.org/) on
one of the tools servers= , and used it to make a collaborative notes
document availab= le for all WGs with a posted agenda for IETF-82.

= You'll find it both linked in and embedded in the minutes page for you= r WG
on tools.ietf.org= ; for an example see http:= //tools.ietf.org/wg/clue/minutes

The no= te documents will be visible on the minutes page until you submit
= official minutes for the meeting, at which time they will be replaced<= /span>
by the minutes.  The etherpad documents will still be a= ccessible directly
at the etherpad URL for some time after t= he meeting, but will be archived
and replaced by new empty d= ocuments before the next meeting.

Comments a= nd suggestions are welcome!


Best regards,

   Henrik=
= --Apple-Mail-6EAE8E53-6FD4-44F7-9929-2B9D7C10E86F-- From gdawra@cisco.com Sat Nov 12 20:57:22 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB4AC21F86A1 for ; Sat, 12 Nov 2011 20:57:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWJHhLLmIp2i for ; Sat, 12 Nov 2011 20:57:22 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0B721F8663 for ; Sat, 12 Nov 2011 20:57:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gdawra@cisco.com; l=3660; q=dns/txt; s=iport; t=1321160242; x=1322369842; h=date:subject:from:to:message-id:in-reply-to:cc: mime-version; bh=AvIufWZZ3UeHbsHXKReHovWyFxL90g10nelkwbPfqc8=; b=WoBf8GtVbstyMFzeJwkXFTxesiUSpC7z2BpGGCqNjfNq9FUgREmOjwzz 46+l/5VTgmZ+xQ37XEJgGRvo6vFRFxtBpgEU/B/cltzGP/rq/nk7vvEVI jv3jCVpW6Pw843wzwmZ9LxIPSQzMipDnXcgJDkfNuqQEtXxJ+Ox4Jv1LW M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAO5Mv06rRDoH/2dsb2JhbABDgk2lAIFqeIEFgXIBAQEDAQEBAQ8BKjEJAgUNAQgEFFUnCQEBBAENBSKHYAiXbgGdIQSJfwSIEIwehUSMUw X-IronPort-AV: E=Sophos;i="4.69,501,1315180800"; d="scan'208,217";a="12235789" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 13 Nov 2011 04:57:22 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pAD4vMDD008203 for ; Sun, 13 Nov 2011 04:57:22 GMT Received: from xmb-sjc-238.amer.cisco.com ([128.107.191.16]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 12 Nov 2011 20:57:21 -0800 Received: from 10.86.253.101 ([10.86.253.101]) by xmb-sjc-238.amer.cisco.com ([128.107.191.16]) via Exchange Front-End Server email.cisco.com ([72.163.63.13]) with Microsoft Exchange Server HTTP-DAV ; Sun, 13 Nov 2011 04:57:21 +0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Sat, 12 Nov 2011 23:57:17 -0500 From: Gaurav Dawra To: Enke Chen , Message-ID: Thread-Topic: [Idr] FW: draft-keyupate-idr-bgp-gr-notification-00.txt - Adoption as working group draft Thread-Index: AcyhwLdrBLKlOq8FsEmkYdijSKVTiA== In-Reply-To: <4EAEE4CE.8060708@cisco.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3403987037_243876" X-OriginalArrivalTime: 13 Nov 2011 04:57:21.0887 (UTC) FILETIME=[BA55A6F0:01CCA1C0] Subject: Re: [Idr] FW: draft-keyupate-idr-bgp-gr-notification-00.txt - Adoption as working group draft X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 04:57:22 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3403987037_243876 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Support. -Gaurav On 10/31/11 11:11 AM, "Enke Chen" wrote: > support. > > -- Enke > > On 10/31/11 11:02 AM, Susan Hares wrote: >> draft-keyupate-idr-bgp-gr-notification-00.txt >> >> >> Folks: >> >> >> >> The authors request the adoption of this draft. >> >> draft-keyupate-idr-bgp-gr-notification-00.txt >> >> >> >> Comments should be sent to the mailing group by November 15th. >> >> Sue and John >> >> >> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr -- Gaurav Dawra, Software Eng. gdawra@cisco.com .:|:.:|:. NSSTG CISCO --B_3403987037_243876 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [Idr] FW: draft-keyupate-idr-bgp-gr-notification-00.txt - Adopti= on as working group draft Support.=

-Gaurav


On 10/31/11 11:11 AM, "Enke Chen" <enkechen@cisco.com> wrote:

  support.
 
 -- Enke
 
 On 10/31/11 11:02 AM, Susan Hares wrote:
  draft-keyupate-idr-bgp-gr-notification-00.txt=  
 

Folks:
 
 
 
The authors request the adoption of this draft.
 
 draft-keyupate-idr-bgp-gr-notification-00.txt
 
 
 
Comments should be sent to the mailing group by November 15th.
 
 Sue and John
 
  
 
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/ma= ilman/listinfo/idr
 

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

--
Gaurav Dawra, Software Eng.
gdawra@cisco.com  .:|:.:|:.
NSSTG            &nb= sp;           CISCO <= BR>
--B_3403987037_243876-- From gdawra@cisco.com Sun Nov 13 07:57:48 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAC7121F8726 for ; Sun, 13 Nov 2011 07:57:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.901 X-Spam-Level: X-Spam-Status: No, score=-5.901 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SV4bM3dW465w for ; Sun, 13 Nov 2011 07:57:48 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 5730C21F86F6 for ; Sun, 13 Nov 2011 07:57:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gdawra@cisco.com; l=1114; q=dns/txt; s=iport; t=1321199869; x=1322409469; h=date:subject:from:to:message-id:in-reply-to:cc: mime-version:content-transfer-encoding; bh=l64cfNmOPnvLY9rse0aVv8TdMJ3Ru9/1+8Dj1e6vj68=; b=LXeq1ZCEuKTrmTCo2unT2VTGE+G6e3D8b7xR9xfA2UUAaUPrQBFdSBbc NraBycx8Zp+/31Niq4dKJ3kSmVGOavTNn8YrpXAomXLo5rvqx9cNJio/L tIzq40yOC16X+qclehruzJuOLhErftpRzSRaPw6lfuivGqVrVfuClEow3 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAHLov06rRDoG/2dsb2JhbABBpxiCYoEFgXIBAQEDAQEBAQ8BJwIBMQkCEgEIGCcuHxEBAQQBDQUih2AIlxoBnTkEiX8EiBCMHoVEjFM X-IronPort-AV: E=Sophos;i="4.69,503,1315180800"; d="scan'208";a="13926216" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 13 Nov 2011 15:57:48 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pADFvm4P025308; Sun, 13 Nov 2011 15:57:48 GMT Received: from xmb-sjc-238.amer.cisco.com ([128.107.191.16]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 13 Nov 2011 07:57:48 -0800 Received: from 10.21.119.144 ([10.21.119.144]) by xmb-sjc-238.amer.cisco.com ([128.107.191.16]) via Exchange Front-End Server email.cisco.com ([171.70.151.174]) with Microsoft Exchange Server HTTP-DAV ; Sun, 13 Nov 2011 15:57:47 +0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Sun, 13 Nov 2011 10:57:45 -0500 From: Gaurav Dawra To: Russ White , Message-ID: Thread-Topic: [Idr] draft-keyupate-idr-bgp-gr-notification-00.txt Thread-Index: AcyiHPuM7hWDEN4QrEOE4FZuE8vHHQ== In-Reply-To: <4EAFD47C.9050904@riw.us> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 13 Nov 2011 15:57:48.0241 (UTC) FILETIME=[FD7B6C10:01CCA21C] Subject: Re: [Idr] draft-keyupate-idr-bgp-gr-notification-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 15:57:48 -0000 Support. Regards, -Gaurav On 11/1/11 4:14 AM, "Russ White" wrote: > > Support. > > Russ > > On 10/31/2011 11:59 PM, Jeff Tantsura wrote: >> Yes/support >> >> Regards, >> Jeff >> >> On Oct 28, 2011, at 18:55, "Keyur Patel" >> > wrote: >> >> Hi Sue and John: >> >> We would like to request that the following draft be adopted as an IDR WG >> document: >> >> draft-keyupate-idr-bgp-gr-notification-00.txt >> >> It was presented at the IETF in Czech Republic. >> >> Regards, >> Keyur >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr -- Gaurav Dawra, Software Eng. gdawra@cisco.com .:|:.:|:. NSSTG CISCO From gdawra@cisco.com Sun Nov 13 08:08:36 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26AD021F8B15 for ; Sun, 13 Nov 2011 08:08:36 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc" X-Spam-Flag: NO X-Spam-Score: -6.25 X-Spam-Level: X-Spam-Status: No, score=-6.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYjQdeb6shdy for ; Sun, 13 Nov 2011 08:08:35 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 86AE321F8B14 for ; Sun, 13 Nov 2011 08:08:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gdawra@cisco.com; l=1013; q=dns/txt; s=iport; t=1321200516; x=1322410116; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=esIbbWNP6u4h49T/gQ5P2tuhCagBQFoO6r4QTUwpRdI=; b=izrU1EmEO6VY57y8Cl7fXprWLyIKDdby+J5aw6XwDtBWWlXuPbHYdaay b+Gy9u5vNTVW+8urJzA64+3vQ6MxoE7mYUQCES8IbRz/V7MlHo6TYBZ3B uZWFKMWMJBOUfnMq5zOjCMdUk0ilkySGYW3yL5CVE7/Cr050KRWajmVrI c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigFAMvqv06rRDoG/2dsb2JhbABCpxiCYoEFgXIBAQEDAQEBAQ8BJwIBMQsSAQgYVTABAQQBDQUih2AIlxoBnTkEiX8EiBCMHoVEjFM X-IronPort-AV: E=Sophos;i="4.69,503,1315180800"; d="scan'208";a="13928339" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 13 Nov 2011 16:08:36 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pADG8a7m030298; Sun, 13 Nov 2011 16:08:36 GMT Received: from xmb-sjc-238.amer.cisco.com ([128.107.191.16]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 13 Nov 2011 08:08:36 -0800 Received: from 10.21.119.144 ([10.21.119.144]) by xmb-sjc-238.amer.cisco.com ([128.107.191.16]) via Exchange Front-End Server email.cisco.com ([171.70.151.187]) with Microsoft Exchange Server HTTP-DAV ; Sun, 13 Nov 2011 16:08:36 +0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Sun, 13 Nov 2011 11:08:36 -0500 From: Gaurav Dawra To: Warren Kumari , John Scudder Message-ID: Thread-Topic: [Idr] draft-keyur-idr-enhanced-gr-00.txt Thread-Index: AcyiHn+TN42CoNVW0kCgYkxp0C74Ng== In-Reply-To: <8C4F7969-69AE-4507-8D54-9C0F6D2AC024@kumari.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 13 Nov 2011 16:08:36.0409 (UTC) FILETIME=[7FD20290:01CCA21E] Cc: Keyur P Patel , "idr@ietf.org List" Subject: Re: [Idr] draft-keyur-idr-enhanced-gr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 16:08:36 -0000 Support. Regards, -Gaurav On 11/1/11 10:22 AM, "Warren Kumari" wrote: > > On Oct 28, 2011, at 4:51 PM, John Scudder wrote: > >> Folks, >> >> Please send comments to the list prior to the IDR meeting on November 15. > > > Support. > W > >> >> Thanks, >> >> --John >> >> On Oct 28, 2011, at 4:49 PM, Enke Chen wrote: >> >>> Hi, Sue and John: >>> >>> We would like to request that the following draft be adopted as an IDR WR >>> document: >>> >>> draft-keyur-idr-enhanced-gr-00.txt >>> >>> It's presented at the last IETF. >>> >>> Thanks. -- Enke >>> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr -- Gaurav Dawra, Software Eng. gdawra@cisco.com .:|:.:|:. NSSTG CISCO From jgs@juniper.net Sun Nov 13 14:20:42 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4F721F8AFD for ; Sun, 13 Nov 2011 14:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JjP-Rd4+Iol for ; Sun, 13 Nov 2011 14:20:41 -0800 (PST) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 6388C21F8ACE for ; Sun, 13 Nov 2011 14:20:41 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKTsBCp3lmyxAlGAyNgE9pVh2IQDLkbBFi@postini.com; Sun, 13 Nov 2011 14:20:41 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Sun, 13 Nov 2011 14:16:02 -0800 From: John Scudder To: "idr@ietf.org List" Date: Sun, 13 Nov 2011 14:16:02 -0800 Thread-Topic: Calls for WG adoption: draft-wkumari-idr-as0-01, draft-keyur-idr-enhanced-gr-00, draft-keyupate-idr-bgp-gr-notification-00 Thread-Index: AcyiUdPZ5w0x5FPTT++ouR3cZlxq3Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Idr] Calls for WG adoption: draft-wkumari-idr-as0-01, draft-keyur-idr-enhanced-gr-00, draft-keyupate-idr-bgp-gr-notification-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: Sun, 13 Nov 2011 22:20:42 -0000 Folks, This is a reminder that we are currently soliciting comments on the adoptio= n of the drafts named in the subject. At the moment, there has been signif= icant support shown for draft-keyupate-idr-bgp-gr-notification-00, but very= little discussion of any kind of draft-keyur-idr-enhanced-gr-00 or draft-w= kumari-idr-as0-01. The deadline for discussion is tomorrow's IDR meeting (November 15 2011, 09= :00 Taipei time). Thanks, --John= From brian.peter.dickson@gmail.com Sun Nov 13 15:16:44 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 559EF21F8888 for ; Sun, 13 Nov 2011 15:16:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.538 X-Spam-Level: X-Spam-Status: No, score=-3.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEwMo8dQO4kv for ; Sun, 13 Nov 2011 15:16:43 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7E221F877F for ; Sun, 13 Nov 2011 15:16:43 -0800 (PST) Received: by bkbzv15 with SMTP id zv15so6487859bkb.31 for ; Sun, 13 Nov 2011 15:16:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fRu4Sk/G7T2erIMyezTegouek14ZBT0pGfLPmRy2Sko=; b=UgZyFmtPLnvirZmq3z0y9qqrEHw/CCoSZNbTqP71mNY6dGttn8kJck9CrsWzvE/I8/ ej0kuol9XI4N7JlDVhgLxfM5dDuTjjgrZ8jVEa6S0TEt61e0Cif8MrSF1Hcyg7btP+/X wBJgXqoIjXlfX1OI9coR75lRMWC/r4FgH7kGk= MIME-Version: 1.0 Received: by 10.204.136.211 with SMTP id s19mr9830340bkt.28.1321226201212; Sun, 13 Nov 2011 15:16:41 -0800 (PST) Received: by 10.223.54.15 with HTTP; Sun, 13 Nov 2011 15:16:41 -0800 (PST) In-Reply-To: References: <8C4F7969-69AE-4507-8D54-9C0F6D2AC024@kumari.net> Date: Sun, 13 Nov 2011 18:16:41 -0500 Message-ID: From: Brian Dickson To: Gaurav Dawra Content-Type: text/plain; charset=ISO-8859-1 Cc: Keyur P Patel , "idr@ietf.org List" Subject: Re: [Idr] draft-keyur-idr-enhanced-gr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 23:16:44 -0000 >> On Oct 28, 2011, at 4:51 PM, John Scudder wrote: >> >>> Folks, >>> >>> Please send comments to the list prior to the IDR meeting on November 15. I have some questions, and some concerns. First, the questions: Was consideration given to implementing this as an optional, non-transitive attribute, instead of as a separate message? Or have the sending party use an attribute with the responder using a message type to acknowledge? Also, have you considered using a "marker" message not associated with a specific NLRI, to simply indicate the latest "window" of messages which has been processed (rather than merely queued up)? One that is sent periodically (and possibly also after N messages). This would behave similar to the "red card" in a casino multi-deck card "shoe", although instead of "shuffle the cards", the semantics would be "everything before this has been received". It would be analogous to TCP sequence numbers, just covering a much larger range of transmitted data, or analogous to DNS serial numbers (kind of). This would work, because each BGP peering session is serialized over a single TCP session. The "marker" is in effect, meta-data used to inform the GR machinery what NLRIs have/have-not been processed, and thus where GR can pick up if GR occurs. IMHO, not only is the overhead less (my orders of magnitude), I think the implementation would be a lot easier, especially when considering interoperability. And, here are the concerns: First, this puts a burden on implementations as far as linking new state to out-RIB. This in turn could, depending on previous implementation choices, have impact on performance tied to things like locking semantics to ensure reliable updates to data structures. Second, this creates a fixed per-NLRI set of additional performance overhead. Consider the "marker" message alternative - how do the two behave during very high demand periods, when significant route updates occur due to major outages (and not only does a significant percentage of the NLRI base get affected, but due to path-hunting, each NLRI is likely to be revisited several or even several dozen times, in a short interval.) Not tying the GR state to individual updates, is likely to minimize the risk of GR degrading performance, at exactly the time where degraded performance becomes a potential causative factor in routing instability and further collapse of the routing infrastructure. Perhaps these questions could be addressed now, prior to adoption? I'm in favor in principal of having GR enhanced, just not with the specific manner embodied in the current draft, with all due respect. (Currently: not in favor.) Brian From brian.peter.dickson@gmail.com Sun Nov 13 15:20:50 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA5EB21F8ADC for ; Sun, 13 Nov 2011 15:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.54 X-Spam-Level: X-Spam-Status: No, score=-3.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17o9-MzFykOA for ; Sun, 13 Nov 2011 15:20:50 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6D821F8AA8 for ; Sun, 13 Nov 2011 15:20:50 -0800 (PST) Received: by bkbzv15 with SMTP id zv15so6490443bkb.31 for ; Sun, 13 Nov 2011 15:20:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=a/l9iPLZ+URg75Sv1SZDqsKrKGeEWkhxfL+dHUBP2/g=; b=XQ00AIX6nec2n/B2+puHXy70X9qt5BDPHsA714AJGTd4/Qn0o2hPnwGyCixz+e4jK3 1aIv62Z7an5smwI4klc5J9/6fR8OG8ZxfB0andI6HWQsZJ1dTfNcB8sXTer+RbiFBIzU /HzsTVZR0Xu/UjDdrknJiLeOFA18c+RSJOCH4= MIME-Version: 1.0 Received: by 10.205.127.16 with SMTP id gy16mr9130564bkc.136.1321226444441; Sun, 13 Nov 2011 15:20:44 -0800 (PST) Received: by 10.223.54.15 with HTTP; Sun, 13 Nov 2011 15:20:44 -0800 (PST) In-Reply-To: <14DD6B3A-B114-4F42-B6D0-37CC377D28C5@juniper.net> References: <7E27D7DD-8A61-43E8-904E-DEDB3B2D2C92@kumari.net> <14DD6B3A-B114-4F42-B6D0-37CC377D28C5@juniper.net> Date: Sun, 13 Nov 2011 18:20:44 -0500 Message-ID: From: Brian Dickson To: John Scudder Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "idr@ietf.org List" Subject: Re: [Idr] Accept draft-wkumari-idr-as0-01.txt ? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 23:20:51 -0000 I have read this (very succinct) draft and support it being adopted as a WG item. (I encourage everyone to read this and voice their opinion, BTW.) I would support it as it stands for WGLC, should there be an interest in su= ch. And also "+ 1,000,000" in level of support. Brian On Fri, Oct 28, 2011 at 4:51 PM, John Scudder wrote: > Folks, > > Please send comments to the list prior to the IDR meeting on November 15. > > Thanks, > > --John > > On Oct 27, 2011, at 9:29 AM, Warren Kumari wrote: > >> Hello IDRites, >> >> I would like to draw your attention to draft-wkumari-idr-as0-01.txt =A0(= http://tools.ietf.org/html/draft-wkumari-idr-as0-01 ) - I am asking that t= his draft be considered for WG adoption. >> >> >> I have already received some feedback, mainly suggesting: >> >> - Add a text for AS number 0 as a reserved in Aggregator and AS4 >> Aggregator attribute >> >> - Add text for AS number 0 as a reserved value in communities and >> extended communities. (RFC 1997 and Four-octet AS Specific Extended >> Communities) >> >> Also suggested was providing a little more information on what to do it = you do receive a route containing AS0 =A0(more descriptive than just "MUST = NOT accept" (for example, stating that it should be "excluded from the Phas= e 2 decision function")). >> >> Anyway, I would value your feedback and input. >> >> W >> >> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From terry@terrym.net Sun Nov 13 17:22:59 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 208EE21F8515 for ; Sun, 13 Nov 2011 17:22:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnooWbraHLyq for ; Sun, 13 Nov 2011 17:22:58 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7A40521F8513 for ; Sun, 13 Nov 2011 17:22:58 -0800 (PST) Received: by ggnr5 with SMTP id r5so412161ggn.31 for ; Sun, 13 Nov 2011 17:22:57 -0800 (PST) Received: by 10.236.178.9 with SMTP id e9mr10948807yhm.77.1321233775859; Sun, 13 Nov 2011 17:22:55 -0800 (PST) Received: from dhcp-25f7.meeting.ietf.org (dhcp-25f7.meeting.ietf.org. [130.129.37.247]) by mx.google.com with ESMTPS id l27sm56355249ani.21.2011.11.13.17.22.53 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 13 Nov 2011 17:22:54 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Terry Manderson In-Reply-To: Date: Mon, 14 Nov 2011 11:22:49 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <3DD4ABBF-8177-4B9B-B652-462B32D52032@terrym.net> References: To: John Scudder X-Mailer: Apple Mail (2.1084) Cc: "idr@ietf.org List" Subject: Re: [Idr] Calls for WG adoption: draft-wkumari-idr-as0-01, X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 01:22:59 -0000 I have read draft-wkumari-idr-as0-01. I think its reasonable to adopt this as an IDR work item to clarify the = standards interpretation of AS0. The text of the document is terse, and I'm not overly comfortable how it = communicates the clarification - but that's not to say the clarification = shouldn't be worked given the adopted use of the nominated AS number for = a routing attestation of non-routability. So I am willing to contribute to ongoing discussion. I'd also like add the universal "what the!" which reflects more on the = SIDR WG when it _was_ discussing the use of the ASO-ROA (versus = alternatives) and it seems the assertions at the time about how AS0's = are actually handled in the BGP documents may well have been over sold = to what is actually in standards space. Call it cognitive dissonance if = you will. Cheers Terry On 14/11/2011, at 8:16 AM, John Scudder wrote: > Folks, >=20 > This is a reminder that we are currently soliciting comments on the = adoption of the drafts named in the subject. At the moment, there has = been significant support shown for = draft-keyupate-idr-bgp-gr-notification-00, but very little discussion of = any kind of draft-keyur-idr-enhanced-gr-00 or draft-wkumari-idr-as0-01. >=20 > The deadline for discussion is tomorrow's IDR meeting (November 15 = 2011, 09:00 Taipei time). >=20 > Thanks, >=20 > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From keyupate@cisco.com Sun Nov 13 17:25:24 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1320421F85F2 for ; Sun, 13 Nov 2011 17:25:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.901 X-Spam-Level: X-Spam-Status: No, score=-5.901 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wuEqdbe-C2Eg for ; Sun, 13 Nov 2011 17:25:23 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 422A321F85B8 for ; Sun, 13 Nov 2011 17:25:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=keyupate@cisco.com; l=735; q=dns/txt; s=iport; t=1321233923; x=1322443523; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=uiaMVijgQrf7gNPx/Euau8TBrd6+IiqxFbUx0pm7H8Y=; b=g3ghqbjFVVTiH/p1yqQ4zhR8GJSS6n75WTmGvUDrhs1tkfsUFDNtXJXn cWEcfhh99iR74qf8xDck0GwfBHk7URpv+xd6v19HEUyoboswfQNMidCw7 XAp69XAVKiBYiVYF12lUJdeMSWX3CbDuXQuGt1goWh7V8uE66X5iAOSxZ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAdtwE6rRDoH/2dsb2JhbABBqXuBBYFyAQEBAwEBAQEPAScCATEJBw0BCA4tMjABAQQBEiKHYAiZKQGdMASJfwSIEIwehUSMVg X-IronPort-AV: E=Sophos;i="4.69,504,1315180800"; d="scan'208";a="13972009" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 14 Nov 2011 01:25:23 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pAE1PN2l010503; Mon, 14 Nov 2011 01:25:23 GMT Received: from xmb-sjc-239.amer.cisco.com ([128.107.191.105]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 13 Nov 2011 17:25:23 -0800 Received: from 10.21.149.236 ([10.21.149.236]) by xmb-sjc-239.amer.cisco.com ([128.107.191.105]) via Exchange Front-End Server email.cisco.com ([128.107.191.87]) with Microsoft Exchange Server HTTP-DAV ; Mon, 14 Nov 2011 01:25:22 +0000 User-Agent: Microsoft-Entourage/12.31.0.110725 Date: Sun, 13 Nov 2011 17:25:24 -0800 From: Keyur Patel To: John Scudder , "idr@ietf.org List" Message-ID: Thread-Topic: [Idr] Calls for WG adoption: draft-wkumari-idr-as0-01, draft-keyur-idr-enhanced-gr-00, draft-keyupate-idr-bgp-gr-notification-00 Thread-Index: AcyiUdPZ5w0x5FPTT++ouR3cZlxq3QAGnRyG In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 14 Nov 2011 01:25:23.0082 (UTC) FILETIME=[47BFC6A0:01CCA26C] Subject: Re: [Idr] Calls for WG adoption: draft-wkumari-idr-as0-01, draft-keyur-idr-enhanced-gr-00, draft-keyupate-idr-bgp-gr-notification-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 01:25:24 -0000 Support draft-wkumari-idr-as0-01. Regards, -Keyur On 11/13/11 2:16 PM, "John Scudder" wrote: > Folks, > > This is a reminder that we are currently soliciting comments on the adoption > of the drafts named in the subject. At the moment, there has been significant > support shown for draft-keyupate-idr-bgp-gr-notification-00, but very little > discussion of any kind of draft-keyur-idr-enhanced-gr-00 or > draft-wkumari-idr-as0-01. > > The deadline for discussion is tomorrow's IDR meeting (November 15 2011, 09:00 > Taipei time). > > Thanks, > > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From christopher.morrow@gmail.com Sun Nov 13 17:25:28 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8D0C11E80D1 for ; Sun, 13 Nov 2011 17:25:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.532 X-Spam-Level: X-Spam-Status: No, score=-103.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkpQrL-PRaYs for ; Sun, 13 Nov 2011 17:25:28 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3586711E80D0 for ; Sun, 13 Nov 2011 17:25:28 -0800 (PST) Received: by iaeo4 with SMTP id o4so8592919iae.31 for ; Sun, 13 Nov 2011 17:25:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Xo/m9X6oSNofft4gsFSJT+EBFzkVzKHbx6xkX/kAIR4=; b=SRMRyxotSd3bB9QQHEDNVWAfyujLpyWRR6Hs4YTMu2ZDEMuuQAYDFLzRGJ/M+weiW4 iEt4OPEJQRveglWvo0RQ+CcXq/GLmJocxTIi6NtCBfanM52HL8luq8O5bSLi01nj5dFK azCuoj14uoLXA0JFfQsyL+v15s8ZFpCZxZNSU= MIME-Version: 1.0 Received: by 10.50.202.100 with SMTP id kh4mr21098713igc.41.1321233927815; Sun, 13 Nov 2011 17:25:27 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.231.202.142 with HTTP; Sun, 13 Nov 2011 17:25:27 -0800 (PST) In-Reply-To: References: <7E27D7DD-8A61-43E8-904E-DEDB3B2D2C92@kumari.net> <14DD6B3A-B114-4F42-B6D0-37CC377D28C5@juniper.net> Date: Sun, 13 Nov 2011 20:25:27 -0500 X-Google-Sender-Auth: cc_qbSm9YIMcH6sT1vSYh2MvBa4 Message-ID: From: Christopher Morrow To: "idr@ietf.org List" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Idr] Accept draft-wkumari-idr-as0-01.txt ? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 01:25:28 -0000 I find it odd that we need this, but accept that it is here... I also would support this work. thanks! -chris From enkechen@cisco.com Sun Nov 13 17:28:38 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6D721F85A1 for ; Sun, 13 Nov 2011 17:28:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.078 X-Spam-Level: X-Spam-Status: No, score=-6.078 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AsBNhBtv6n69 for ; Sun, 13 Nov 2011 17:28:37 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id E266021F858C for ; Sun, 13 Nov 2011 17:28:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=5607; q=dns/txt; s=iport; t=1321234117; x=1322443717; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=Pw6JzWlP7GE0Mit48cWoaTMcq4vRXn5PkhnlUVUxHNw=; b=VoIsO1YNFa/1EtMWU/I9mkUt1i22SxgWqb5Q8xRhUrcGgNIxFV7KWyEA q51fm/Neo0jbHOQ9gWhTJsgW1vSYQoK8EEJKr2S33jizbdWVOh6knsaNa Nfe5YmjVTbg4nkLfBjw5IPyiQBTXkeOWXjH9221Ccj7hPd8eB6ZWMug/d M=; X-IronPort-AV: E=Sophos;i="4.69,504,1315180800"; d="scan'208,217";a="14014717" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 14 Nov 2011 01:28:37 +0000 Received: from sjc-vpn7-1185.cisco.com (sjc-vpn7-1185.cisco.com [10.21.148.161]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pAE1SaIO021875; Mon, 14 Nov 2011 01:28:36 GMT Message-ID: <4EC06F20.9020906@cisco.com> Date: Sun, 13 Nov 2011 17:30:08 -0800 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: idr@ietf.org References: <7E27D7DD-8A61-43E8-904E-DEDB3B2D2C92@kumari.net> <14DD6B3A-B114-4F42-B6D0-37CC377D28C5@juniper.net> In-Reply-To: <14DD6B3A-B114-4F42-B6D0-37CC377D28C5@juniper.net> Content-Type: multipart/alternative; boundary="------------080800060405000805030007" Subject: Re: [Idr] Accept draft-wkumari-idr-as0-01.txt ? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 01:28:38 -0000 This is a multi-part message in MIME format. --------------080800060405000805030007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Support, but with the following suggestions: 1) Nit: change "bgp listener" to "bgp speaker". 2) The following language is not very precise. Due to the incremental nature, we will need to remove the existing route too. ----- a BGP listener MUST NOT accept an announcement which has an AS number of zero in the AS-PATH attribute, and SHOULD log the fact that it has done so. ----- How about the following: An UPDATE message that contains the AS number of zero in the AS-PATH attribute MUST be considered as malformed, and be handled by the procedures specified in draft-ietf-idr-optional-transitive-04.txt 3) If this draft is adopted, we should also add AS 0 as one of the error conditions in rfc4893bis. Thanks. -- Enke On 10/28/11 1:51 PM, John Scudder wrote: > Folks, > > Please send comments to the list prior to the IDR meeting on November 15. > > Thanks, > > --John > > On Oct 27, 2011, at 9:29 AM, Warren Kumari wrote: > >> Hello IDRites, >> >> I would like to draw your attention to draft-wkumari-idr-as0-01.txt (http://tools.ietf.org/html/draft-wkumari-idr-as0-01 ) - I am asking that this draft be considered for WG adoption. >> >> >> I have already received some feedback, mainly suggesting: >> >> - Add a text for AS number 0 as a reserved in Aggregator and AS4 >> Aggregator attribute >> >> - Add text for AS number 0 as a reserved value in communities and >> extended communities. (RFC 1997 and Four-octet AS Specific Extended >> Communities) >> >> Also suggested was providing a little more information on what to do it you do receive a route containing AS0 (more descriptive than just "MUST NOT accept" (for example, stating that it should be "excluded from the Phase 2 decision function")). >> >> Anyway, I would value your feedback and input. >> >> W >> >> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --------------080800060405000805030007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
Support, but with the following suggestions:

1) Nit: change "bgp listener" to "bgp speaker".

2) The following language is not very precise.  Due to the incremental nature, we will need to remove the existing route too.

-----
   a BGP
   listener MUST NOT accept an announcement which has an AS number of
   zero in the AS-PATH attribute, and SHOULD log the fact that it has
   done so.
-----

   How about the following:

   An UPDATE message that contains the AS number of zero in the AS-PATH attribute
   MUST be considered as malformed, and be handled by the procedures specified in
   draft-ietf-idr-optional-transitive-04.txt

3) If this draft is adopted, we should also add AS 0 as one of the error conditions in
rfc4893bis.

Thanks.   -- Enke
On 10/28/11 1:51 PM, John Scudder wrote: 
Folks,

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

Thanks,

--John

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


Hello IDRites,

I would like to draw your attention to draft-wkumari-idr-as0-01.txt  ( http://tools.ietf.org/html/draft-wkumari-idr-as0-01 ) - I am asking that this draft be considered for WG adoption.


I have already received some feedback, mainly suggesting:

- Add a text for AS number 0 as a reserved in Aggregator and AS4
Aggregator attribute

- Add text for AS number 0 as a reserved value in communities and
extended communities. (RFC 1997 and Four-octet AS Specific Extended
Communities)

Also suggested was providing a little more information on what to do it you do receive a route containing AS0  (more descriptive than just "MUST NOT accept" (for example, stating that it should be "excluded from the Phase 2 decision function")).

Anyway, I would value your feedback and input.

W



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

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


--------------080800060405000805030007-- From jeff.tantsura@ericsson.com Sun Nov 13 17:39:44 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1795C11E808B for ; Sun, 13 Nov 2011 17:39:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3ri5GmGjDUo for ; Sun, 13 Nov 2011 17:39:43 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5921621F8783 for ; Sun, 13 Nov 2011 17:39:43 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pAE1PseZ026111; Sun, 13 Nov 2011 19:25:55 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.111]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Sun, 13 Nov 2011 20:25:54 -0500 From: Jeff Tantsura To: John Scudder Date: Sun, 13 Nov 2011 20:25:58 -0500 Thread-Topic: [Idr] Accept draft-wkumari-idr-as0-01.txt ? Thread-Index: AcyibFpI9HzYFhG0TECTImaYTBetYQ== Message-ID: <6006BD7F-3CFA-44D8-914C-3FCAE2C59A86@ericsson.com> References: <7E27D7DD-8A61-43E8-904E-DEDB3B2D2C92@kumari.net> <14DD6B3A-B114-4F42-B6D0-37CC377D28C5@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org List" Subject: Re: [Idr] Accept draft-wkumari-idr-as0-01.txt ? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 01:39:44 -0000 +1 Regards, Jeff >=20 > On Fri, Oct 28, 2011 at 4:51 PM, John Scudder wrote: >> Folks, >>=20 >> Please send comments to the list prior to the IDR meeting on November 15= . >>=20 >> Thanks, >>=20 >> --John >>=20 >> On Oct 27, 2011, at 9:29 AM, Warren Kumari wrote: >>=20 >>> Hello IDRites, >>>=20 >>> I would like to draw your attention to draft-wkumari-idr-as0-01.txt ( = http://tools.ietf.org/html/draft-wkumari-idr-as0-01 ) - I am asking that th= is draft be considered for WG adoption. >>>=20 >>>=20 >>> I have already received some feedback, mainly suggesting: >>>=20 >>> - Add a text for AS number 0 as a reserved in Aggregator and AS4 >>> Aggregator attribute >>>=20 >>> - Add text for AS number 0 as a reserved value in communities and >>> extended communities. (RFC 1997 and Four-octet AS Specific Extended >>> Communities) >>>=20 >>> Also suggested was providing a little more information on what to do it= you do receive a route containing AS0 (more descriptive than just "MUST N= OT accept" (for example, stating that it should be "excluded from the Phase= 2 decision function")). >>>=20 >>> Anyway, I would value your feedback and input. >>>=20 >>> W >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr >>=20 >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >>=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From aservin@lacnic.net Sun Nov 13 17:48:09 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B75101F0C5A for ; Sun, 13 Nov 2011 17:48:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.204 X-Spam-Level: X-Spam-Status: No, score=-1.204 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVmABG-xeZU5 for ; Sun, 13 Nov 2011 17:48:09 -0800 (PST) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id D761E1F0C45 for ; Sun, 13 Nov 2011 17:48:08 -0800 (PST) Received: from [IPv6:2001:df8::16:7077:f636:130d:66d4] (unknown [IPv6:2001:df8:0:16:7077:f636:130d:66d4]) by mail.lacnic.net.uy (Postfix) with ESMTP id DB6A6308427; Sun, 13 Nov 2011 23:48:05 -0200 (UYST) References: <7E27D7DD-8A61-43E8-904E-DEDB3B2D2C92@kumari.net> In-Reply-To: <7E27D7DD-8A61-43E8-904E-DEDB3B2D2C92@kumari.net> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (9A334) From: Arturo Servin Date: Sun, 13 Nov 2011 23:48:46 -0200 To: Warren Kumari X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: "idr@ietf.org" Subject: Re: [Idr] Accept draft-wkumari-idr-as0-01.txt ? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 01:48:09 -0000 Warren, Wouldn't this be a DoS attack vector if the attacker originates a valid pref= ix with ASN0? It wouldn't be a global attack, but it may generate some local black holes f= or the victim, is it? Regards, -as On 27 Oct 2011, at 11:29, Warren Kumari wrote: > Hello IDRites, >=20 > I would like to draw your attention to draft-wkumari-idr-as0-01.txt ( htt= p://tools.ietf.org/html/draft-wkumari-idr-as0-01 ) - I am asking that this d= raft be considered for WG adoption. >=20 >=20 > I have already received some feedback, mainly suggesting: >=20 > - Add a text for AS number 0 as a reserved in Aggregator and AS4 > Aggregator attribute >=20 > - Add text for AS number 0 as a reserved value in communities and > extended communities. (RFC 1997 and Four-octet AS Specific Extended > Communities) >=20 > Also suggested was providing a little more information on what to do it yo= u do receive a route containing AS0 (more descriptive than just "MUST NOT a= ccept" (for example, stating that it should be "excluded from the Phase 2 de= cision function")). >=20 > Anyway, I would value your feedback and input. >=20 > W >=20 >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From altonlo@cisco.com Sun Nov 13 17:57:30 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6162221F8505 for ; Sun, 13 Nov 2011 17:57:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xtBTR4UCy69 for ; Sun, 13 Nov 2011 17:57:29 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 71EDE21F8509 for ; Sun, 13 Nov 2011 17:57:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=altonlo@cisco.com; l=773; q=dns/txt; s=iport; t=1321235843; x=1322445443; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=e1aanQYLQaR0kp1Vb8Ij65Eukt2LG/CCOK89RsKuZek=; b=Y0ZBAzBpTwrVSrIVjMxy2e9aD0cp7eLEe42JvvtMjBXFgCXG2hgS3pfp 4RJx666R+Qz/hzVmJW/tcec7dmuJHeG1UOkHtsxhQkMGnAE067lgk95Ji jMpXzgWDBd/A7osC6NOr0pDstvouoqW33+4lsgWQJvhiJC+hJ9zyHaoWs I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAC51wE6rRDoJ/2dsb2JhbABBqXuBBYFyAQEBAwEBAQEPAScCATEJBw0BCAkFLTIwAQEEARIih2AImWYBnTYEiX8EiBCEfIcihUSMVg X-IronPort-AV: E=Sophos;i="4.69,504,1315180800"; d="scan'208";a="13974187" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 14 Nov 2011 01:57:23 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pAE1vNH4019435; Mon, 14 Nov 2011 01:57:23 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 13 Nov 2011 17:57:23 -0800 Received: from 10.21.93.96 ([10.21.93.96]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Mon, 14 Nov 2011 01:57:22 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Sun, 13 Nov 2011 17:57:19 -0800 From: altonlo To: John Scudder , "idr@ietf.org List" Message-ID: Thread-Topic: [Idr] Calls for WG adoption: draft-wkumari-idr-as0-01, draft-keyur-idr-enhanced-gr-00, draft-keyupate-idr-bgp-gr-notification-00 Thread-Index: AcyiUdPZ5w0x5FPTT++ouR3cZlxq3QAHuniy In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 14 Nov 2011 01:57:23.0273 (UTC) FILETIME=[C045AB90:01CCA270] Subject: Re: [Idr] Calls for WG adoption: draft-wkumari-idr-as0-01, draft-keyur-idr-enhanced-gr-00, draft-keyupate-idr-bgp-gr-notification-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 01:57:30 -0000 Support both draft-keyur-idr-enhanced-gr-00 and draft-wkumari-idr-as0-01 Thanks, -alton On 11/13/11 2:16 PM, "John Scudder" wrote: > Folks, > > This is a reminder that we are currently soliciting comments on the adoption > of the drafts named in the subject. At the moment, there has been significant > support shown for draft-keyupate-idr-bgp-gr-notification-00, but very little > discussion of any kind of draft-keyur-idr-enhanced-gr-00 or > draft-wkumari-idr-as0-01. > > The deadline for discussion is tomorrow's IDR meeting (November 15 2011, 09:00 > Taipei time). > > Thanks, > > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From randy@psg.com Sun Nov 13 18:04:32 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7A111E8109 for ; Sun, 13 Nov 2011 18:04:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pz9Yobd3l0aF for ; Sun, 13 Nov 2011 18:04:31 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id D1EE611E8121 for ; Sun, 13 Nov 2011 18:04:25 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RPluK-000PvY-SK; Mon, 14 Nov 2011 02:04:25 +0000 Date: Mon, 14 Nov 2011 10:04:23 +0800 Message-ID: From: Randy Bush To: John Scudder In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IETF IDR Subject: Re: [Idr] Calls for WG adoption: draft-wkumari-idr-as0-01, draft-keyur-idr-enhanced-gr-00, draft-keyupate-idr-bgp-gr-notification-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 02:04:32 -0000 i support enhanced-gr and bgp-gr-notification randy From brian.peter.dickson@gmail.com Sun Nov 13 18:13:34 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2482711E8073 for ; Sun, 13 Nov 2011 18:13:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.541 X-Spam-Level: X-Spam-Status: No, score=-3.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTWsUvHE0qFF for ; Sun, 13 Nov 2011 18:13:33 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 35E2C11E8081 for ; Sun, 13 Nov 2011 18:13:33 -0800 (PST) Received: by bkbzv15 with SMTP id zv15so6606217bkb.31 for ; Sun, 13 Nov 2011 18:13:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=WL9hP5Kb2zJKbRDxEarUqNCUW3aLMfQBObcEjodzIo4=; b=Iv11IpOxc4zXLsKoOct3dncI2WxA2BO5Zsm8nQ9ospOOwTBGbTaSMZQY5ARIc6wa+E wtRcpyd1NUdVcz6Wa6aMMml4++ZESYknnfVrTBouNs8YuaZJd0MxonWHlLTUF7htuLYl 5wKKWFDVfENEF5k2K6Ooi7VkHUn7fiHrSqq9E= MIME-Version: 1.0 Received: by 10.204.130.90 with SMTP id r26mr5228787bks.46.1321236811988; Sun, 13 Nov 2011 18:13:31 -0800 (PST) Received: by 10.223.54.15 with HTTP; Sun, 13 Nov 2011 18:13:31 -0800 (PST) In-Reply-To: References: <8C4F7969-69AE-4507-8D54-9C0F6D2AC024@kumari.net> Date: Sun, 13 Nov 2011 21:13:31 -0500 Message-ID: From: Brian Dickson To: "idr@ietf.org List" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Idr] draft-keyur-idr-enhanced-gr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 02:13:34 -0000 Forgive my previous comments, please. They were based on a mis-reading of the draft. Support. Brian On Sun, Nov 13, 2011 at 6:16 PM, Brian Dickson wrote: >>> On Oct 28, 2011, at 4:51 PM, John Scudder wrote: >>> >>>> Folks, >>>> >>>> Please send comments to the list prior to the IDR meeting on November 15. > > I have some questions, and some concerns. > > First, the questions: > > Was consideration given to implementing this as an optional, > non-transitive attribute, instead of as a separate message? Or have > the sending party use an attribute with the responder using a message > type to acknowledge? > > Also, have you considered using a "marker" message not associated with > a specific NLRI, to simply indicate the latest "window" of messages > which has been processed (rather than merely queued up)? One that is > sent periodically (and possibly also after N messages). This would > behave similar to the "red card" in a casino multi-deck card "shoe", > although instead of "shuffle the cards", the semantics would be > "everything before this has been received". It would be analogous to > TCP sequence numbers, just covering a much larger range of transmitted > data, or analogous to DNS serial numbers (kind of). This would work, > because each BGP peering session is serialized over a single TCP > session. The "marker" is in effect, meta-data used to inform the GR > machinery what NLRIs have/have-not been processed, and thus where GR > can pick up if GR occurs. IMHO, not only is the overhead less (my > orders of magnitude), I think the implementation would be a lot > easier, especially when considering interoperability. > > And, here are the concerns: > > First, this puts a burden on implementations as far as linking new > state to out-RIB. This in turn could, depending on previous > implementation choices, have impact on performance tied to things like > locking semantics to ensure reliable updates to data structures. > > Second, this creates a fixed per-NLRI set of additional performance > overhead. Consider the "marker" message alternative - how do the two > behave during very high demand periods, when significant route updates > occur due to major outages (and not only does a significant percentage > of the NLRI base get affected, but due to path-hunting, each NLRI is > likely to be revisited several or even several dozen times, in a short > interval.) Not tying the GR state to individual updates, is likely to > minimize the risk of GR degrading performance, at exactly the time > where degraded performance becomes a potential causative factor in > routing instability and further collapse of the routing > infrastructure. > > Perhaps these questions could be addressed now, prior to adoption? > > I'm in favor in principal of having GR enhanced, just not with the > specific manner embodied in the current draft, with all due respect. > > (Currently: not in favor.) > > Brian > From jakob.heitz@ericsson.com Sun Nov 13 18:45:23 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56E8A1F0C90 for ; Sun, 13 Nov 2011 18:45:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.262 X-Spam-Level: X-Spam-Status: No, score=-6.262 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlInwy-nqR0u for ; Sun, 13 Nov 2011 18:45:22 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id B43B01F0C8F for ; Sun, 13 Nov 2011 18:45:22 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id pAE2jLDs009834 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 13 Nov 2011 20:45:21 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.111]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Sun, 13 Nov 2011 21:45:20 -0500 From: Jakob Heitz To: Enke Chen Date: Sun, 13 Nov 2011 21:46:01 -0500 Thread-Topic: [Idr] Accept draft-wkumari-idr-as0-01.txt ? Thread-Index: Acyid3MDhUmGykAjQjKpa+DsneRKBw== Message-ID: <493C1D64-07EE-4FCD-8F75-1FEA233C329D@ericsson.com> References: <7E27D7DD-8A61-43E8-904E-DEDB3B2D2C92@kumari.net> <14DD6B3A-B114-4F42-B6D0-37CC377D28C5@juniper.net> <4EC06F20.9020906@cisco.com> In-Reply-To: <4EC06F20.9020906@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "idr@ietf.org" Subject: Re: [Idr] Accept draft-wkumari-idr-as0-01.txt ? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 02:45:23 -0000 KzEgKEVua2UncyBzdWdnZXN0aW9uKQ0KDQotLQ0KSmFrb2IgSGVpdHouDQoNCg0KT24gTm92IDEz LCAyMDExLCBhdCA1OjI4IFBNLCAiRW5rZSBDaGVuIiA8ZW5rZWNoZW5AY2lzY28uY29tPG1haWx0 bzplbmtlY2hlbkBjaXNjby5jb20+PiB3cm90ZToNCg0KDQpTdXBwb3J0LCBidXQgd2l0aCB0aGUg Zm9sbG93aW5nIHN1Z2dlc3Rpb25zOg0KDQoxKSBOaXQ6IGNoYW5nZSAiYmdwIGxpc3RlbmVyIiB0 byAiYmdwIHNwZWFrZXIiLg0KDQoyKSBUaGUgZm9sbG93aW5nIGxhbmd1YWdlIGlzIG5vdCB2ZXJ5 IHByZWNpc2UuICBEdWUgdG8gdGhlIGluY3JlbWVudGFsIG5hdHVyZSwgd2Ugd2lsbCBuZWVkIHRv IHJlbW92ZSB0aGUgZXhpc3Rpbmcgcm91dGUgdG9vLg0KDQotLS0tLQ0KICAgYSBCR1ANCiAgIGxp c3RlbmVyIE1VU1QgTk9UIGFjY2VwdCBhbiBhbm5vdW5jZW1lbnQgd2hpY2ggaGFzIGFuIEFTIG51 bWJlciBvZg0KICAgemVybyBpbiB0aGUgQVMtUEFUSCBhdHRyaWJ1dGUsIGFuZCBTSE9VTEQgbG9n IHRoZSBmYWN0IHRoYXQgaXQgaGFzDQogICBkb25lIHNvLg0KLS0tLS0NCg0KICAgSG93IGFib3V0 IHRoZSBmb2xsb3dpbmc6DQoNCiAgIEFuIFVQREFURSBtZXNzYWdlIHRoYXQgY29udGFpbnMgdGhl IEFTIG51bWJlciBvZiB6ZXJvIGluIHRoZSBBUy1QQVRIIGF0dHJpYnV0ZQ0KICAgTVVTVCBiZSBj b25zaWRlcmVkIGFzIG1hbGZvcm1lZCwgYW5kIGJlIGhhbmRsZWQgYnkgdGhlIHByb2NlZHVyZXMg c3BlY2lmaWVkIGluDQogICBkcmFmdC1pZXRmLWlkci1vcHRpb25hbC10cmFuc2l0aXZlLTA0LnR4 dA0KDQozKSBJZiB0aGlzIGRyYWZ0IGlzIGFkb3B0ZWQsIHdlIHNob3VsZCBhbHNvIGFkZCBBUyAw IGFzIG9uZSBvZiB0aGUgZXJyb3IgY29uZGl0aW9ucyBpbg0KcmZjNDg5M2Jpcy4NCg0KVGhhbmtz LiAgIC0tIEVua2UNCg0KDQoNCk9uIDEwLzI4LzExIDE6NTEgUE0sIEpvaG4gU2N1ZGRlciB3cm90 ZToNCg0KRm9sa3MsDQoNClBsZWFzZSBzZW5kIGNvbW1lbnRzIHRvIHRoZSBsaXN0IHByaW9yIHRv IHRoZSBJRFIgbWVldGluZyBvbiBOb3ZlbWJlciAxNS4NCg0KVGhhbmtzLA0KDQotLUpvaG4NCg0K T24gT2N0IDI3LCAyMDExLCBhdCA5OjI5IEFNLCBXYXJyZW4gS3VtYXJpIHdyb3RlOg0KDQoNCg0K SGVsbG8gSURSaXRlcywNCg0KSSB3b3VsZCBsaWtlIHRvIGRyYXcgeW91ciBhdHRlbnRpb24gdG8g ZHJhZnQtd2t1bWFyaS1pZHItYXMwLTAxLnR4dCAgKCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC13a3VtYXJpLWlkci1hczAtMDEgKSAtIEkgYW0gYXNraW5nIHRoYXQgdGhpcyBkcmFm dCBiZSBjb25zaWRlcmVkIGZvciBXRyBhZG9wdGlvbi4NCg0KDQpJIGhhdmUgYWxyZWFkeSByZWNl aXZlZCBzb21lIGZlZWRiYWNrLCBtYWlubHkgc3VnZ2VzdGluZzoNCg0KLSBBZGQgYSB0ZXh0IGZv ciBBUyBudW1iZXIgMCBhcyBhIHJlc2VydmVkIGluIEFnZ3JlZ2F0b3IgYW5kIEFTNA0KQWdncmVn YXRvciBhdHRyaWJ1dGUNCg0KLSBBZGQgdGV4dCBmb3IgQVMgbnVtYmVyIDAgYXMgYSByZXNlcnZl ZCB2YWx1ZSBpbiBjb21tdW5pdGllcyBhbmQNCmV4dGVuZGVkIGNvbW11bml0aWVzLiAoUkZDIDE5 OTcgYW5kIEZvdXItb2N0ZXQgQVMgU3BlY2lmaWMgRXh0ZW5kZWQNCkNvbW11bml0aWVzKQ0KDQpB bHNvIHN1Z2dlc3RlZCB3YXMgcHJvdmlkaW5nIGEgbGl0dGxlIG1vcmUgaW5mb3JtYXRpb24gb24g d2hhdCB0byBkbyBpdCB5b3UgZG8gcmVjZWl2ZSBhIHJvdXRlIGNvbnRhaW5pbmcgQVMwICAobW9y ZSBkZXNjcmlwdGl2ZSB0aGFuIGp1c3QgIk1VU1QgTk9UIGFjY2VwdCIgKGZvciBleGFtcGxlLCBz dGF0aW5nIHRoYXQgaXQgc2hvdWxkIGJlICJleGNsdWRlZCBmcm9tIHRoZSBQaGFzZSAyIGRlY2lz aW9uIGZ1bmN0aW9uIikpLg0KDQpBbnl3YXksIEkgd291bGQgdmFsdWUgeW91ciBmZWVkYmFjayBh bmQgaW5wdXQuDQoNClcNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpJZHIgbWFpbGluZyBsaXN0DQpJZHJAaWV0Zi5vcmc8bWFpbHRvOklkckBp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklkciBtYWls aW5nIGxpc3QNCklkckBpZXRmLm9yZzxtYWlsdG86SWRyQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHINCg0KDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZHIgbWFpbGluZyBsaXN0DQpJZHJAaWV0Zi5v cmc8bWFpbHRvOklkckBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaWRyDQo= From ilya@nobulus.com Sun Nov 13 19:06:14 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD5541F0CB6 for ; Sun, 13 Nov 2011 19:06:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Z3lwlOT9+k1 for ; Sun, 13 Nov 2011 19:06:14 -0800 (PST) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by ietfa.amsl.com (Postfix) with ESMTP id 16D381F0CAD for ; Sun, 13 Nov 2011 19:06:14 -0800 (PST) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id 228DD1749F; Mon, 14 Nov 2011 04:06:12 +0100 (CET) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6IhKJtqrCxgf; Mon, 14 Nov 2011 04:06:09 +0100 (CET) Received: from hnivarlas1 (unknown [IPv6:2001:df8:0:16:31ab:b3cd:433e:7a41]) by nobulus.com (Postfix) with ESMTPA id 1E22317141; Mon, 14 Nov 2011 04:06:05 +0100 (CET) Message-ID: <7AA66493681846C0995A24141ADC6165@hnivarlas1> From: "iLya" To: "John Scudder" , References: In-Reply-To: Date: Mon, 14 Nov 2011 04:05:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 Subject: Re: [Idr] Calls for WG adoption: draft-wkumari-idr-as0-01, draft-keyur-idr-enhanced-gr-00, draft-keyupate-idr-bgp-gr-notification-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 03:06:14 -0000 As an operator I find draft-keyur-idr-enhanced-gr-00 very useful and support adopting it as WG document. /iLya -------------------------------------------------- From: "John Scudder" Sent: Sunday, November 13, 2011 11:16 PM To: Subject: [Idr] Calls for WG adoption: draft-wkumari-idr-as0-01, draft-keyur-idr-enhanced-gr-00, draft-keyupate-idr-bgp-gr-notification-00 > Folks, > > This is a reminder that we are currently soliciting comments on the > adoption of the drafts named in the subject. At the moment, there has > been significant support shown for > draft-keyupate-idr-bgp-gr-notification-00, but very little discussion of > any kind of draft-keyur-idr-enhanced-gr-00 or draft-wkumari-idr-as0-01. > > The deadline for discussion is tomorrow's IDR meeting (November 15 2011, > 09:00 Taipei time). > > Thanks, > > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > From bvenkata@cisco.com Sun Nov 13 20:17:07 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB50A11E8095 for ; Sun, 13 Nov 2011 20:17:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ib0qeZH9E+H6 for ; Sun, 13 Nov 2011 20:17:07 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id CF5C011E8086 for ; Sun, 13 Nov 2011 20:17:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bvenkata@cisco.com; l=817; q=dns/txt; s=iport; t=1321244226; x=1322453826; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=ovGOC01sffbT3O3gxEE+b+QmK0GntcZe944DKrtQbp4=; b=MTckmY8H9WLtlTidw+fG0YkchqI7FsUWduZV11ItLSEZ9qBa/JlCwQAM mbsrxUTbPG2Pd+1/+wUZxZJVuxydqTqVyGq/yqim2dn1JFEX3TtXVZac8 xklWyFHAiYfi+08n2azEFRv2F0IIpS+Q/NqPp5pt2aHz8zZ/pK6pHO+gu Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYAAK6VwE5Io8UR/2dsb2JhbABCmXeQBoEFgXIBAQEDAQEBAQ8BHQo0CwUHBAIBCA4DBAEBCwYXAQYBJh8JCAEBBAEKCAgah2AImWYBnT8EiRxjBIgOkWSMPQ X-IronPort-AV: E=Sophos;i="4.69,505,1315180800"; d="scan'208";a="2983098" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-4.cisco.com with ESMTP; 14 Nov 2011 04:16:59 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pAE4GwT2021386; Mon, 14 Nov 2011 04:16:58 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Nov 2011 09:46:58 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Nov 2011 09:46:55 +0530 Message-ID: In-Reply-To: <404F0C7A-5866-46AA-BD99-767D865E9FFE@juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-keyur-idr-enhanced-gr-00.txt Thread-Index: AcyVs2y39olZ1bXNR1OimTEEss8HCAM0Lm8A References: <4EAB1545.3000201@cisco.com> <404F0C7A-5866-46AA-BD99-767D865E9FFE@juniper.net> From: "Balaji Pitta Venkatachalapathy (bvenkata)" To: "John Scudder" , X-OriginalArrivalTime: 14 Nov 2011 04:16:58.0296 (UTC) FILETIME=[402CC380:01CCA284] Cc: "Keyur Patel \(keyupate\)" Subject: Re: [Idr] draft-keyur-idr-enhanced-gr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 04:17:07 -0000 Support!! Regards, Balaji -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of John Scudder Sent: Friday, October 28, 2011 1:52 PM To: idr@ietf.org List Cc: Keyur Patel (keyupate) Subject: Re: [Idr] draft-keyur-idr-enhanced-gr-00.txt Folks, Please send comments to the list prior to the IDR meeting on November 15. Thanks, --John On Oct 28, 2011, at 4:49 PM, Enke Chen wrote: > Hi, Sue and John: >=20 > We would like to request that the following draft be adopted as an IDR WR document: >=20 > draft-keyur-idr-enhanced-gr-00.txt >=20 > It's presented at the last IETF. >=20 > Thanks. -- Enke >=20 _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From jeff.tantsura@ericsson.com Sun Nov 13 21:18:12 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99AEC21F8AB0 for ; Sun, 13 Nov 2011 21:18:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OolnF79Tljbm for ; Sun, 13 Nov 2011 21:18:12 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 068CD21F8AAF for ; Sun, 13 Nov 2011 21:18:11 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pAE5IAgA031892; Sun, 13 Nov 2011 23:18:11 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.111]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 14 Nov 2011 00:18:04 -0500 From: Jeff Tantsura To: "idr@ietf.org" Date: Mon, 14 Nov 2011 00:18:10 -0500 Thread-Topic: [Idr] draft-keyur-idr-enhanced-gr-00.txt Thread-Index: AcyijMlxL+OQWkT/Rq2dCM7WktYe8g== Message-ID: References: <4EAB1545.3000201@cisco.com> <404F0C7A-5866-46AA-BD99-767D865E9FFE@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Keyur Patel \(keyupate\)" Subject: Re: [Idr] draft-keyur-idr-enhanced-gr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 05:18:12 -0000 Very useful addition to GR! Yes/support Regards, Jeff >=20 > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of > John Scudder > Sent: Friday, October 28, 2011 1:52 PM > To: idr@ietf.org List > Cc: Keyur Patel (keyupate) > Subject: Re: [Idr] draft-keyur-idr-enhanced-gr-00.txt >=20 > Folks, >=20 > Please send comments to the list prior to the IDR meeting on November > 15. >=20 > Thanks, >=20 > --John >=20 > On Oct 28, 2011, at 4:49 PM, Enke Chen wrote: >=20 >> Hi, Sue and John: >>=20 >> We would like to request that the following draft be adopted as an IDR > WR document: >>=20 >> draft-keyur-idr-enhanced-gr-00.txt >>=20 >> It's presented at the last IETF. >>=20 >> Thanks. -- Enke >>=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ >=20 From jakob.heitz@ericsson.com Sun Nov 13 21:26:26 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AED971F0C4F for ; Sun, 13 Nov 2011 21:26:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.282 X-Spam-Level: X-Spam-Status: No, score=-6.282 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JClCId-iHBH for ; Sun, 13 Nov 2011 21:26:26 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 108E61F0C34 for ; Sun, 13 Nov 2011 21:26:26 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pAE5QMow032070; Sun, 13 Nov 2011 23:26:23 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.111]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 14 Nov 2011 00:26:16 -0500 From: Jakob Heitz To: Enke Chen Date: Mon, 14 Nov 2011 00:26:59 -0500 Thread-Topic: [Idr] draft-keyur-idr-enhanced-gr-00.txt Thread-Index: Acyije5eS+Ysl67/QRqwu9ZqE5EvLg== Message-ID: <4D409033-6B6E-46D2-840E-27D37714BBF3@ericsson.com> References: <4EAB1545.3000201@cisco.com> In-Reply-To: <4EAB1545.3000201@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Keyur Patel , "idr@ietf.org" Subject: Re: [Idr] draft-keyur-idr-enhanced-gr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 05:26:26 -0000 Support. -- Jakob Heitz. On Oct 28, 2011, at 1:48 PM, "Enke Chen" wrote: > Hi, Sue and John: >=20 > We would like to request that the following draft be adopted as an IDR WR= document: >=20 > draft-keyur-idr-enhanced-gr-00.txt >=20 > It's presented at the last IETF. >=20 > Thanks. -- Enke >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From bhavani@cisco.com Sun Nov 13 21:27:17 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F31841F0C5F for ; Sun, 13 Nov 2011 21:27:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRiZCfgo2xo0 for ; Sun, 13 Nov 2011 21:27:16 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE941F0C34 for ; Sun, 13 Nov 2011 21:27:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bhavani@cisco.com; l=2271; q=dns/txt; s=iport; t=1321248436; x=1322458036; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=5R7N9VWURY4L4Ouz8ois5s5YSyteBjdTHKjPirAt9y8=; b=hWO74OmNlN+6HnFQPZzVDE0ZGWdXpigeq4bW8/FC/1SsibNStXbwAv1B ZrqdAjq3yM6nt7mc54qJ6bGHAN2+dTwKIlfrWh0/31RWIUosr1Q+El7Y5 U/P6OkIsV7kfQB/wKSNB4Qlfiftgmdp3hBjjv8YsX33W2J6epyIaIKsf8 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEmmwE6rRDoI/2dsb2JhbABCqX2BBYFyAQEBBAEBAQ8BWwoRCwQBEwkWDwkDAgECARUwEwYCAQEeh2iZJAGdQASGaoMVBIgQjB6FO4xf X-IronPort-AV: E=Sophos;i="4.69,506,1315180800"; d="scan'208,217";a="13991587" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 14 Nov 2011 05:27:16 +0000 Received: from [10.21.166.104] ([10.21.166.104]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pAE5RGEi005702 for ; Mon, 14 Nov 2011 05:27:16 GMT Message-ID: <4EC0A6B3.7090304@cisco.com> Date: Sun, 13 Nov 2011 21:27:15 -0800 From: Bhavani Parise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: idr@ietf.org References: <4EAB1545.3000201@cisco.com> <404F0C7A-5866-46AA-BD99-767D865E9FFE@juniper.net> In-Reply-To: <404F0C7A-5866-46AA-BD99-767D865E9FFE@juniper.net> Content-Type: multipart/alternative; boundary="------------050403060401040900080102" Subject: Re: [Idr] draft-keyur-idr-enhanced-gr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 05:27:17 -0000 This is a multi-part message in MIME format. --------------050403060401040900080102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Support. regards, Bhavani On 10/28/2011 1:51 PM, John Scudder wrote: > Folks, > > Please send comments to the list prior to the IDR meeting on November 15. > > Thanks, > > --John > > On Oct 28, 2011, at 4:49 PM, Enke Chen wrote: > >> Hi, Sue and John: >> >> We would like to request that the following draft be adopted as an IDR WR document: >> >> draft-keyur-idr-enhanced-gr-00.txt >> >> It's presented at the last IETF. >> >> Thanks. -- Enke >> > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --------------050403060401040900080102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Support.

regards,
Bhavani

On 10/28/2011 1:51 PM, John Scudder wrote: 
Folks,

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

Thanks,

--John

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


Hi, Sue and John:

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

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

It's presented at the last IETF.

Thanks.   -- Enke


_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr
--------------050403060401040900080102-- From wim.henderickx@alcatel-lucent.com Sun Nov 13 21:31:20 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1D9C11E80D4 for ; Sun, 13 Nov 2011 21:31:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.198 X-Spam-Level: X-Spam-Status: No, score=-6.198 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Teyr3Pgg6JrT for ; Sun, 13 Nov 2011 21:31:19 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id AA10911E80B2 for ; Sun, 13 Nov 2011 21:31:18 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id pAE5VD0Y008581 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 14 Nov 2011 06:31:13 +0100 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.42]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Mon, 14 Nov 2011 06:31:13 +0100 From: "Henderickx, Wim (Wim)" To: Bhavani Parise , "idr@ietf.org" Date: Mon, 14 Nov 2011 06:31:07 +0100 Thread-Topic: [Idr] draft-keyur-idr-enhanced-gr-00.txt Thread-Index: AcyijhiOE2/gNQkSQHKvIbK9w9t6QwAAIA+g Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D671BCB1F6B@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <4EAB1545.3000201@cisco.com> <404F0C7A-5866-46AA-BD99-767D865E9FFE@juniper.net> <4EC0A6B3.7090304@cisco.com> In-Reply-To: <4EC0A6B3.7090304@cisco.com> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: multipart/alternative; boundary="_000_14C7F4F06DB5814AB0DE29716C4F6D671BCB1F6BFRMRSSXCHMBSB1d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [Idr] draft-keyur-idr-enhanced-gr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 05:31:20 -0000 --_000_14C7F4F06DB5814AB0DE29716C4F6D671BCB1F6BFRMRSSXCHMBSB1d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Bhava= ni Parise Sent: maandag 14 november 2011 6:27 To: idr@ietf.org Subject: Re: [Idr] draft-keyur-idr-enhanced-gr-00.txt Support. regards, Bhavani On 10/28/2011 1:51 PM, John Scudder wrote: Folks, Please send comments to the list prior to the IDR meeting on November 15. Thanks, --John On Oct 28, 2011, at 4:49 PM, Enke Chen wrote: Hi, Sue and John: We would like to request that the following draft be adopted as an IDR WR d= ocument: draft-keyur-idr-enhanced-gr-00.txt It's presented at the last IETF. Thanks. -- Enke _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_14C7F4F06DB5814AB0DE29716C4F6D671BCB1F6BFRMRSSXCHMBSB1d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= +1

 

From:= idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf O= f Bhavani Parise
Sent: maandag 14 november 2011 6:27
To= : idr@ietf.org
Subject: Re: [Idr] draft-keyur-idr-enhanced-gr= -00.txt

 


Support.

regards,
Bhavani

On 10/28/2011 1:51 PM, John Scud= der wrote: 

Folks,
 
Please send comments to the list prior to the IDR meeting on No=
vember 15.
 
Thanks,
 
--John
=
 
On Oct 28, 2011, at 4:49 PM, Enke Chen wrote:
 
Hi, Sue and John:
&nbs=
p;
We would like to request that the following draft be ado=
pted as an IDR WR document:
 
     draft-keyur-idr-enhanced-gr-00.txt
 
It's presented at the last IETF.
 
Thanks.   -- Enke=

 
 =

_______________________________________________
= 
Idr mailing list
=
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr
= --_000_14C7F4F06DB5814AB0DE29716C4F6D671BCB1F6BFRMRSSXCHMBSB1d_-- From pierre.francois@imdea.org Sun Nov 13 22:23:40 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1423B11E80BE for ; Sun, 13 Nov 2011 22:23:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-tUDmNMJxkM for ; Sun, 13 Nov 2011 22:23:39 -0800 (PST) Received: from estafeta.imdea.org (maquina44.madrimasd.org [193.145.15.44]) by ietfa.amsl.com (Postfix) with ESMTP id 11B9A11E8095 for ; Sun, 13 Nov 2011 22:23:39 -0800 (PST) Received: from localhost (estafeta21.imdea.org [172.17.99.144]) by estafeta21.imdea.org (Postfix) with ESMTP id 5B18718901E for ; Mon, 14 Nov 2011 07:23:37 +0100 (CET) X-Virus-Scanned: by antispam-antivirus system at imdea.org Received: from estafeta.imdea.org ([172.17.99.144]) by localhost (estafeta21.imdea.org [172.17.99.144]) (amavisd-new, port 10024) with ESMTP id wc6HObYb95rH for ; Mon, 14 Nov 2011 07:23:37 +0100 (CET) Received: from dhcp-167f.meeting.ietf.org (dhcp-167f.meeting.ietf.org [130.129.22.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pierre.francois) by estafeta21.imdea.org (Postfix) with ESMTP id 479D018901D for ; Mon, 14 Nov 2011 07:23:34 +0100 (CET) Message-ID: <4EC0B3E2.30301@imdea.org> Date: Mon, 14 Nov 2011 07:23:30 +0100 From: Pierre Francois User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 CC: "idr@ietf.org" References: <4EAB1545.3000201@cisco.com> <404F0C7A-5866-46AA-BD99-767D865E9FFE@juniper.net> <4EC0A6B3.7090304@cisco.com> <14C7F4F06DB5814AB0DE29716C4F6D671BCB1F6B@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D671BCB1F6B@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Content-Type: multipart/alternative; boundary="------------000900000601030006050606" Subject: Re: [Idr] draft-keyur-idr-enhanced-gr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 06:23:40 -0000 This is a multi-part message in MIME format. --------------000900000601030006050606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Support. Pierre. On 11/14/11 6:31 AM, Henderickx, Wim (Wim) wrote: > > +1 > > *From:*idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] *On Behalf > Of *Bhavani Parise > *Sent:* maandag 14 november 2011 6:27 > *To:* idr@ietf.org > *Subject:* Re: [Idr] draft-keyur-idr-enhanced-gr-00.txt > > > Support. > > regards, > Bhavani > > On 10/28/2011 1:51 PM, John Scudder wrote: > > Folks, > > Please send comments to the list prior to the IDR meeting on November 15. > > Thanks, > > --John > > On Oct 28, 2011, at 4:49 PM, Enke Chen wrote: > > > Hi, Sue and John: > > > > We would like to request that the following draft be adopted as an IDR WR document: > > > > draft-keyur-idr-enhanced-gr-00.txt > > > > It's presented at the last IETF. > > > > Thanks. -- Enke > > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --------------000900000601030006050606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi,

Support.

Pierre.

On 11/14/11 6:31 AM, Henderickx, Wim (Wim) wrote:

+1

 

From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Bhavani Parise
Sent: maandag 14 november 2011 6:27
To: idr@ietf.org
Subject: Re: [Idr] draft-keyur-idr-enhanced-gr-00.txt

 


Support.

regards,
Bhavani

On 10/28/2011 1:51 PM, John Scudder wrote: 

Folks,
 
Please send comments to the list prior to the IDR meeting on November 15.
 
Thanks,
 
--John
 
On Oct 28, 2011, at 4:49 PM, Enke Chen wrote:
 
Hi, Sue and John:
 
We would like to request that the following draft be adopted as an IDR WR document:
 
     draft-keyur-idr-enhanced-gr-00.txt
 
It's presented at the last IETF.
 
Thanks.   -- Enke
 
 
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr


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

--------------000900000601030006050606-- From danny@tcb.net Sun Nov 13 23:20:29 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBAD511E80B3 for ; Sun, 13 Nov 2011 23:20:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+ch6wkjXVK3 for ; Sun, 13 Nov 2011 23:20:29 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 262FC21F8558 for ; Sun, 13 Nov 2011 23:20:29 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 09ADA268063; Mon, 14 Nov 2011 00:20:22 -0700 (MST) Received: from dhcp-1267.meeting.ietf.org (130.129.18.103 [130.129.18.103]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 14 Nov 2011 00:20:21 -0700 (MST) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=130.129.18.103; client-port=54366; client-dnsfail=130.129.18.103: name server failure; syn-fingerprint=65535:48:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: Date: Mon, 14 Nov 2011 02:20:04 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3B492F3B-2558-436C-8C09-D50A8D4FFBEF@tcb.net> References: To: John Scudder X-Mailer: Apple Mail (2.1084) Cc: "idr@ietf.org List" Subject: Re: [Idr] Calls for WG adoption: draft-wkumari-idr-as0-01, draft-keyur-idr-enhanced-gr-00, draft-keyupate-idr-bgp-gr-notification-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 07:20:29 -0000 On Nov 13, 2011, at 5:16 PM, John Scudder wrote: > Folks, >=20 > This is a reminder that we are currently soliciting comments on the = adoption of the drafts named in the subject. At the moment, there has = been significant support shown for = draft-keyupate-idr-bgp-gr-notification-00, but very little discussion of = any kind of draft-keyur-idr-enhanced-gr-00 or draft-wkumari-idr-as0-01. I support adoption of this as a WG item _with Enke's recommended text. I would like to see consistent use of AS_PATH (v., AS-PATH and AS PATH). = =20 Also, it seems a bit redundant to list Randy as an author AND in the=20 acknowledgements as a primary text contributor, not sure how that=20 happened ;-) -danny= From jie.dong@huawei.com Mon Nov 14 01:11:54 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B9721F8508 for ; Mon, 14 Nov 2011 01:11:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.351 X-Spam-Level: X-Spam-Status: No, score=-6.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXLQmmuZhpvZ for ; Mon, 14 Nov 2011 01:11:46 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id B532121F8F45 for ; Mon, 14 Nov 2011 01:11:44 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUN00I0P87CTW@szxga05-in.huawei.com> for idr@ietf.org; Mon, 14 Nov 2011 17:11:36 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUN008QZ87BIF@szxga05-in.huawei.com> for idr@ietf.org; Mon, 14 Nov 2011 17:11:36 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEZ03504; Mon, 14 Nov 2011 17:11:35 +0800 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 14 Nov 2011 17:11:32 +0800 Received: from SZXEML509-MBS.china.huawei.com ([169.254.2.220]) by szxeml411-hub.china.huawei.com ([10.82.67.138]) with mapi id 14.01.0323.003; Mon, 14 Nov 2011 17:11:27 +0800 Date: Mon, 14 Nov 2011 09:11:26 +0000 From: Jie Dong In-reply-to: X-Originating-IP: [172.24.2.40] To: Gaurav Dawra , Russ White , "idr@ietf.org" Message-id: <76CD132C3ADEF848BD84D028D243C92722A18149@szxeml509-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [Idr] draft-keyupate-idr-bgp-gr-notification-00.txt Thread-index: AcyV3dH5lc/eBPTQ+kql8WhTfRu0UwCKcRIAAA8uOQACZWeRgAA00oWO X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4EAFD47C.9050904@riw.us> Subject: Re: [Idr] draft-keyupate-idr-bgp-gr-notification-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 09:11:54 -0000 Support. Regards, Jie ________________________________________ From: idr-bounces@ietf.org [idr-bounces@ietf.org] on behalf of Gaurav Dawra [gdawra@cisco.com] Sent: Sunday, November 13, 2011 23:57 To: Russ White; idr@ietf.org Subject: Re: [Idr] draft-keyupate-idr-bgp-gr-notification-00.txt Support. Regards, -Gaurav On 11/1/11 4:14 AM, "Russ White" wrote: > > Support. > > Russ > > On 10/31/2011 11:59 PM, Jeff Tantsura wrote: >> Yes/support >> >> Regards, >> Jeff >> >> On Oct 28, 2011, at 18:55, "Keyur Patel" >> > wrote: >> >> Hi Sue and John: >> >> We would like to request that the following draft be adopted as an IDR WG >> document: >> >> draft-keyupate-idr-bgp-gr-notification-00.txt >> >> It was presented at the IETF in Czech Republic. >> >> Regards, >> Keyur >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr -- Gaurav Dawra, Software Eng. gdawra@cisco.com .:|:.:|:. NSSTG CISCO _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From kotikalapudi.sriram@nist.gov Mon Nov 14 01:21:30 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 052E021F8512 for ; Mon, 14 Nov 2011 01:21:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.231 X-Spam-Level: X-Spam-Status: No, score=-5.231 tagged_above=-999 required=5 tests=[AWL=-1.232, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQYgk6Zqx--N for ; Mon, 14 Nov 2011 01:21:23 -0800 (PST) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF9521F8DDF for ; Mon, 14 Nov 2011 01:21:07 -0800 (PST) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.339.1; Mon, 14 Nov 2011 04:21:03 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Mon, 14 Nov 2011 04:20:27 -0500 From: "Sriram, Kotikalapudi" To: "idr@ietf.org" Date: Mon, 14 Nov 2011 04:20:26 -0500 Thread-Topic: Calls for WG adoption: draft-wkumari-idr-as0-01, draft-keyur-idr-enhanced-gr-00, draft-keyupate-idr-bgp-gr-notification-00 Thread-Index: AQHMoq6lPukDszH2j06o2AO+punfmw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Subject: Re: [Idr] Calls for WG adoption: draft-wkumari-idr-as0-01, draft-keyur-idr-enhanced-gr-00, draft-keyupate-idr-bgp-gr-notification-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 09:21:32 -0000 I support all three. Sriram From russw@riw.us Mon Nov 14 06:18:03 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7F921F8D83 for ; Mon, 14 Nov 2011 06:18:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DxR0KEsGmZK4 for ; Mon, 14 Nov 2011 06:18:03 -0800 (PST) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 3B76A21F8D7F for ; Mon, 14 Nov 2011 06:18:03 -0800 (PST) Received: from rrcs-24-199-145-66.midsouth.biz.rr.com ([24.199.145.66]:31560 helo=[192.168.3.115]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RPxMH-0007vO-HT for idr@ietf.org; Mon, 14 Nov 2011 09:18:01 -0500 Message-ID: <4EC12313.3030604@riw.us> Date: Mon, 14 Nov 2011 09:17:55 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: idr@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Subject: Re: [Idr] draft-keyur-idr-enhanced-gr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 14:18:03 -0000 Support. :-) Russ On 11/13/2011 11:08 AM, Gaurav Dawra wrote: > Support. > > Regards, > -Gaurav > > > On 11/1/11 10:22 AM, "Warren Kumari" wrote: > >> >> On Oct 28, 2011, at 4:51 PM, John Scudder wrote: >> >>> Folks, >>> >>> Please send comments to the list prior to the IDR meeting on November 15. >> >> >> Support. >> W >> >>> >>> Thanks, >>> >>> --John >>> >>> On Oct 28, 2011, at 4:49 PM, Enke Chen wrote: >>> >>>> Hi, Sue and John: >>>> >>>> We would like to request that the following draft be adopted as an IDR WR >>>> document: >>>> >>>> draft-keyur-idr-enhanced-gr-00.txt >>>> >>>> It's presented at the last IETF. >>>> >>>> Thanks. -- Enke >>>> >>> >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr >>> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > From naiming@cisco.com Mon Nov 14 08:30:05 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D71B51F0C67 for ; Mon, 14 Nov 2011 08:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.342 X-Spam-Level: X-Spam-Status: No, score=-6.342 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGa0NhdVi5q1 for ; Mon, 14 Nov 2011 08:30:05 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 481331F0C5C for ; Mon, 14 Nov 2011 08:30:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=naiming@cisco.com; l=1374; q=dns/txt; s=iport; t=1321288205; x=1322497805; h=subject:mime-version:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=63tRyAYcHu9MFN2lbBvagnwVWM6qFqZUbY3PM9c3txc=; b=PAXScA8N/4VZAKqecQ+bEjUYew0JX2y1u8CdF1o/OEJwOPEhM9C7CRyA Iu3hcgBtGpTmqIwbSp/6Vygtxolk9o3KtXMSXoiWOJ7hp9mrdkCPw9qfM OUHbDp/KUwncPXDvVKUAwsO/Ezlpx+5Yif7U7fHZgJTAcUJyxeAlQU/5v I=; X-IronPort-AV: E=Sophos;i="4.69,509,1315180800"; d="scan'208";a="14118267" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 14 Nov 2011 16:30:05 +0000 Received: from sjc-vpn4-202.cisco.com (sjc-vpn4-202.cisco.com [10.21.80.202]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAEGU4N3001200; Mon, 14 Nov 2011 16:30:05 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Naiming Shen In-Reply-To: <4EC12313.3030604@riw.us> Date: Mon, 14 Nov 2011 08:30:03 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5ACF1790-F9B1-4DDD-AE03-B7DA7C4894FC@cisco.com> References: <4EC12313.3030604@riw.us> To: idr@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [Idr] draft-keyur-idr-enhanced-gr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 16:30:05 -0000 +1. - Naiming On Nov 14, 2011, at 6:17 AM, Russ White wrote: >=20 > Support. >=20 > :-) >=20 > Russ >=20 > On 11/13/2011 11:08 AM, Gaurav Dawra wrote: >> Support. >>=20 >> Regards, >> -Gaurav >>=20 >>=20 >> On 11/1/11 10:22 AM, "Warren Kumari" wrote: >>=20 >>>=20 >>> On Oct 28, 2011, at 4:51 PM, John Scudder wrote: >>>=20 >>>> Folks, >>>>=20 >>>> Please send comments to the list prior to the IDR meeting on = November 15. >>>=20 >>>=20 >>> Support. >>> W >>>=20 >>>>=20 >>>> Thanks, >>>>=20 >>>> --John >>>>=20 >>>> On Oct 28, 2011, at 4:49 PM, Enke Chen wrote: >>>>=20 >>>>> Hi, Sue and John: >>>>>=20 >>>>> We would like to request that the following draft be adopted as an = IDR WR >>>>> document: >>>>>=20 >>>>> draft-keyur-idr-enhanced-gr-00.txt >>>>>=20 >>>>> It's presented at the last IETF. >>>>>=20 >>>>> Thanks. -- Enke >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Idr mailing list >>>> Idr@ietf.org >>>> https://www.ietf.org/mailman/listinfo/idr >>>>=20 >>>=20 >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr >>=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From shsethur@cisco.com Mon Nov 14 18:04:41 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C51AD1F0C6C for ; Mon, 14 Nov 2011 18:04:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2y6HiBX0gaLL for ; Mon, 14 Nov 2011 18:04:41 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6941F0C3F for ; Mon, 14 Nov 2011 18:04:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shsethur@cisco.com; l=832; q=dns/txt; s=iport; t=1321322681; x=1322532281; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=3mDaU13Jxjum30WWwJkfqCfEjfdyMmg1E/VKrSsZJLM=; b=CnjlOX1zj4Ymg+7f9OVZc8gegVqLudogzOs2la8QoZpG1Rd+OCQenfbB TkITVuHkU2jaC8LYf01rbtpDFlunPMcK+OJO93/vGKXlIfL0RioLs0O57 lYdzr3Rij8Ytp6BC9YgReZVxJnfJWlqk9PS3wdJ9Wezt0Hdv6CVcPz3C5 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At4AADTIwU6rRDoI/2dsb2JhbABDmWSQBYEFgXIBAQEEAQEBDwEdCjQLDAQCAQgOAwQBAQEKBhcBBgEmHwkIAQEEARIIGodom1QBnnoEiRxjBIgQkWKMVg X-IronPort-AV: E=Sophos;i="4.69,512,1315180800"; d="scan'208";a="12536168" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 15 Nov 2011 02:04:40 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pAF24eSh005629; Tue, 15 Nov 2011 02:04:40 GMT Received: from xmb-sjc-227.amer.cisco.com ([128.107.191.43]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Nov 2011 18:04:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Nov 2011 18:04:39 -0800 Message-ID: In-Reply-To: <404F0C7A-5866-46AA-BD99-767D865E9FFE@juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-keyur-idr-enhanced-gr-00.txt Thread-Index: AcyVs2y39olZ1bXNR1OimTEEss8HCANh39ng References: <4EAB1545.3000201@cisco.com> <404F0C7A-5866-46AA-BD99-767D865E9FFE@juniper.net> From: "Shyam Sethuram (shsethur)" To: "John Scudder" , X-OriginalArrivalTime: 15 Nov 2011 02:04:40.0898 (UTC) FILETIME=[EF87B220:01CCA33A] Cc: "Keyur Patel \(keyupate\)" Subject: Re: [Idr] draft-keyur-idr-enhanced-gr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 02:04:41 -0000 Support. thanks--shyam >-----Original Message----- >From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of John Scudder >Sent: Friday, October 28, 2011 1:52 PM >To: idr@ietf.org List >Cc: Keyur Patel (keyupate) >Subject: Re: [Idr] draft-keyur-idr-enhanced-gr-00.txt > >Folks, > >Please send comments to the list prior to the IDR meeting on November 15. > >Thanks, > >--John > >On Oct 28, 2011, at 4:49 PM, Enke Chen wrote: > >> Hi, Sue and John: >> >> We would like to request that the following draft be adopted as an IDR WR document: >> >> draft-keyur-idr-enhanced-gr-00.txt >> >> It's presented at the last IETF. >> >> Thanks. -- Enke >> > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From warren@kumari.net Mon Nov 14 18:06:56 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 802E01F0CBF for ; Mon, 14 Nov 2011 18:06:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3OAM0l0F1QeC for ; Mon, 14 Nov 2011 18:06:56 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id EABE91F0CF2 for ; Mon, 14 Nov 2011 18:06:55 -0800 (PST) Received: from [172.30.23.144] (unknown [72.14.229.161]) by vimes.kumari.net (Postfix) with ESMTPSA id 7BEA61B406E8; Mon, 14 Nov 2011 21:06:54 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Tue, 15 Nov 2011 10:06:50 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <70AD0CC7-B32A-4B93-B9A2-2A5856DE30FF@kumari.net> References: To: Gaurav Dawra X-Mailer: Apple Mail (2.1084) Cc: Keyur P Patel , "idr@ietf.org List" Subject: Re: [Idr] draft-keyur-idr-enhanced-gr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 02:06:56 -0000 Cannot remember if I already sent this or not, but : Support. On Nov 14, 2011, at 12:08 AM, Gaurav Dawra wrote: > Support. >=20 > Regards, > -Gaurav >=20 >=20 > On 11/1/11 10:22 AM, "Warren Kumari" wrote: >=20 >>=20 >> On Oct 28, 2011, at 4:51 PM, John Scudder wrote: >>=20 >>> Folks, >>>=20 >>> Please send comments to the list prior to the IDR meeting on = November 15. >>=20 >>=20 >> Support. >> W >>=20 >>>=20 >>> Thanks, >>>=20 >>> --John >>>=20 >>> On Oct 28, 2011, at 4:49 PM, Enke Chen wrote: >>>=20 >>>> Hi, Sue and John: >>>>=20 >>>> We would like to request that the following draft be adopted as an = IDR WR >>>> document: >>>>=20 >>>> draft-keyur-idr-enhanced-gr-00.txt >>>>=20 >>>> It's presented at the last IETF. >>>>=20 >>>> Thanks. -- Enke >>>>=20 >>>=20 >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr >>>=20 >>=20 >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >=20 > --=20 > Gaurav Dawra, Software Eng. > gdawra@cisco.com .:|:.:|:. > NSSTG CISCO >=20 >=20 From shsethur@cisco.com Mon Nov 14 18:13:16 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79FC911E8100 for ; Mon, 14 Nov 2011 18:13:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jbm2lMFraj-A for ; Mon, 14 Nov 2011 18:13:15 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id A30B021F8D44 for ; Mon, 14 Nov 2011 18:13:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shsethur@cisco.com; l=572; q=dns/txt; s=iport; t=1321323195; x=1322532795; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=r7n3HLCVBp5myPZsrSoedM1aA0Wzm+aOYDWZoic6sak=; b=WRmNt1DhRUiRkSCQPTcAcvc4j7O1tYf44dGcPxIN3HrY5LhzmZSnc6DO Oho2rJs41mbobySEF96zIzsaGIeCbukfMbq+tQaCtfROIzDIJY1EK01N8 2AMweLN6HRmCoQmUpBgKEr9HKP0EiIe1olH82R0ul5vGmVhizUr7NCu9u c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At4AABrKwU6rRDoH/2dsb2JhbABDmWSQBYEFgXIBAQEEEgEdCj0OBAIBCBEEAQELBhcBBgFFCQgBAQQBEggao0cBnn+JHGMEiBCRYoxW X-IronPort-AV: E=Sophos;i="4.69,512,1315180800"; d="scan'208";a="14235227" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 15 Nov 2011 02:13:15 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pAF2DFe6031715; Tue, 15 Nov 2011 02:13:15 GMT Received: from xmb-sjc-227.amer.cisco.com ([128.107.191.43]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Nov 2011 18:13:15 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Nov 2011 18:13:08 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-keyupate-idr-bgp-gr-notification-00.txt Thread-Index: AcyV3dH5lc/eBPTQ+kql8WhTfRu0UwNXkj1Q References: From: "Shyam Sethuram (shsethur)" To: "Keyur Patel (keyupate)" , "John Scudder" , "Rex Fernando (rex)" , , X-OriginalArrivalTime: 15 Nov 2011 02:13:15.0282 (UTC) FILETIME=[22207720:01CCA33C] Subject: Re: [Idr] draft-keyupate-idr-bgp-gr-notification-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 02:13:16 -0000 Support. thanks--shyam >-----Original Message----- >From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Keyur Patel >(keyupate) >Sent: Friday, October 28, 2011 6:55 PM >To: John Scudder; Rex Fernando (rex); jhaas@juniper.net; idr@ietf.org >Subject: [Idr] draft-keyupate-idr-bgp-gr-notification-00.txt > >Hi Sue and John: > >We would like to request that the following draft be adopted as an IDR WG document: > >draft-keyupate-idr-bgp-gr-notification-00.txt > >It was presented at the IETF in Czech Republic. > >Regards, >Keyur From jgs@juniper.net Mon Nov 14 18:23:31 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8D711E835A for ; Mon, 14 Nov 2011 18:23:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.512 X-Spam-Level: X-Spam-Status: No, score=-6.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4iOXv55TRZ2B for ; Mon, 14 Nov 2011 18:23:31 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id DF36611E8357 for ; Mon, 14 Nov 2011 18:23:30 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKTsHNIuf8bNEz1MjgPqZxPogqfCqfc/wt@postini.com; Mon, 14 Nov 2011 18:23:30 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Mon, 14 Nov 2011 18:22:29 -0800 From: John Scudder To: "idr@ietf.org List" Date: Mon, 14 Nov 2011 18:22:32 -0800 Thread-Topic: [Idr] Calls for WG adoption: draft-wkumari-idr-as0-01, draft-keyur-idr-enhanced-gr-00, draft-keyupate-idr-bgp-gr-notification-00 Thread-Index: AcyjPWw7122urH5/RgqnQ6WDIjgGFg== Message-ID: <5EBAE0B8-F22F-4842-BB1A-94A8F69DCF7B@juniper.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] Calls for WG adoption: draft-wkumari-idr-as0-01, draft-keyur-idr-enhanced-gr-00, draft-keyupate-idr-bgp-gr-notification-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, 15 Nov 2011 02:23:31 -0000 These discussion periods have closed; all the above named drafts are adopte= d. Thanks for the input, everyone. Authors, please resubmit as draft-ietf= -idr-. --John On Nov 14, 2011, at 6:16 AM, John Scudder wrote: > Folks, >=20 > This is a reminder that we are currently soliciting comments on the adopt= ion of the drafts named in the subject. At the moment, there has been sign= ificant support shown for draft-keyupate-idr-bgp-gr-notification-00, but ve= ry little discussion of any kind of draft-keyur-idr-enhanced-gr-00 or draft= -wkumari-idr-as0-01. >=20 > The deadline for discussion is tomorrow's IDR meeting (November 15 2011, = 09:00 Taipei time). >=20 > Thanks, >=20 > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From ju1738@att.com Mon Nov 14 19:09:19 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4A0E1F0C9A for ; Mon, 14 Nov 2011 19:09:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.398 X-Spam-Level: X-Spam-Status: No, score=-105.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0JFdGlc2pcJ for ; Mon, 14 Nov 2011 19:09:06 -0800 (PST) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1911F0C98 for ; Mon, 14 Nov 2011 19:09:06 -0800 (PST) X-Env-Sender: ju1738@att.com X-Msg-Ref: server-12.tower-120.messagelabs.com!1321326543!35259448!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8907 invoked from network); 15 Nov 2011 03:09:03 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-12.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Nov 2011 03:09:03 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pAF39UtZ015222; Mon, 14 Nov 2011 22:09:31 -0500 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pAF39OqS015115 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Nov 2011 22:09:24 -0500 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([169.254.1.53]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.01.0339.001; Mon, 14 Nov 2011 22:08:56 -0500 From: "UTTARO, JAMES" To: "UTTARO, JAMES" , "'Enke Chen'" Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-00 Thread-Index: AQHMkEAnLP0iAkRlVkChUYWtkZqOMZWKuQoAgAQhplCAAIdcwoABIPrwgAESmgCABpCw8IAVN//Q Date: Tue, 15 Nov 2011 03:08:55 +0000 Message-ID: References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net> <4EA84254.9000400@raszuk.net> <4EA8A91C.4090305@cisco.com> <4EAA496C.9070605@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.160.253] Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550FA324FAMISOUT7MSGUSR9IIT_" MIME-Version: 1.0 Cc: "'idr@ietf.org List'" , "'robert@raszuk.net'" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 03:09:19 -0000 --_000_B17A6910EEDD1F45980687268941550FA324FAMISOUT7MSGUSR9IIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, First let me apologize for not being able to attend the iet= f.. After watching jabber it seems that the presentation of per= sistence degraded to something in re how we can apply multiple Band-Aids, p= atches, knobs etc... to extend GR to cover the Persistence draft.. IMO GR i= s a subset of the Persistence functionality and may be therefore subsumed i= nto the Persistence draft. Philosophically GR makes the session the invaria= nt and all behavior that follows is based upon this premise.. As stated in = the slides, many of the new services have much looser association between t= he control and forwarding planes i.e L2VN, L3VPN, 3107 etc... Again let me clarify, when I looked at GR earlier this year it became clea= r that the basic philosophy, and rules stating when to persist, how long, t= riggers to stop would not meet the requirements I have.. From a philosophic= al point GR assumes that the paths that are persisting in forwarding should= maintain their preference throughout the routing topology. Why? This seems= beyond prescriptive as it does not provide the network operators with any = flexibility as to how state learned over a compromised control may be view= ed/used by the downstream routing topology including customers. From my rea= ding of the draft there is no way to allow operators to persist, not-persis= t, or de pref the state (stale). Do I have this wrong? I do not think so..= So if we want to incorporate this ability into GR it would require a basic= philosophical change.. of course even if this is done there is no way for = a peer to pre-program paths it has advertised to be treated if there is a = failure.. So, even if we perform major surgery there is still no way to acc= omplish this beyond unique filters and maybe CVs.. WE could call them STALE= , PERSIST and DO_NOT_PERSIST and then build routing policy across all of ou= r BGP speakers.. Then we can spends lots of time making sure that this bott= om approach is consistent across the entire topology, and coordinate with c= ustomers also.. As I mentioned in a previous note ( see below ) GR does not meet requiremen= ts in terms of triggers that terminate GR persistence, timers etc... perso= nally I am not that interested in a solution that fundamentally does not m= eet my requirements.. Most of the responses I have received is that GR can = be extended. I do not think it can ever meet the requirements above and wil= l require major surgery to fix the triggers, timers etc.. So the approach s= hould be to fold the subset of GR functionality into the larger Persistence= draft.. Jim Uttaro Enke, GR is a solution that is essentially local in scope it does not have the ab= ility to inform downstream speakers of the viability of routing state from = the point of possible control plane failure. OTOH Persistence does propagat= e the condition of state. This provides distinct advantages in terms of cus= tomers awareness of the SPs control plane. One could imagine a customer rec= eiving a STALE path and responding by selecting a backup. Some of the exten= sions to this draft that I have considered in colouring of STALE to inform = if the condition arises from a local ( PE ) or internal iBGP ( RR ) failure= s.. GR makes no distinction from STALE state and ACTIVE state.. This can lead t= o the STALE path still being preferred throughout the topology. IMO this is= incorrect behavior regardless of the comparison. PERSISTENCE allows for a customer to indicate which paths should be candida= tes. Customers may want to immediately failover to the backup for some path= s and not for others. GR is not capable of doing this it is all or nothing.= The granularity is not sufficient. It needs to be at the path level. There= may even be a case for having even more granularity i.e a per path timer..= GR is not capable of being extended for either of these cases. GR does not provide protection through successive restarts of the session. = I believe that if this occurs the state will be invalidated. So for a sessi= on that is bouncing due to overload condition GR will not provide the requi= red protection GR does not employ a make before break strategy. All state is invalidated f= irst then the newly learned state is processed. This leads to routing churn= especially if the majority of the state is the same which I am pretty sure= is the case GR invalidates state due to the case of protocol error i.e A malformed upda= te will invalidate all of the state. This is not the desired behavior. GR is not specific as to which events invoke it or not. From my read on the= draft it is not clear if holdtime expiration invokes GR or not.. The draft= is unclear. It is not clear to me how RRs and PEs differ in using GR. The time that state can persist is limit to about 1 hour max. GR does detail the behavior where convergence is not achieved between resta= rts.. Similar to above.. I do not believe that the current GR paradigm can be extended to cover the = majority of the cases above. Thanks, Jim Uttaro From: UTTARO, JAMES Sent: Tuesday, November 01, 2011 11:20 AM To: 'Enke Chen' Cc: robert@raszuk.net; idr@ietf.org List Subject: RE: [Idr] draft-uttaro-idr-bgp-persistence-00 Enke, Comments in-Line.. Thanks, Jim Uttaro From: Enke Chen [mailto:enkechen@cisco.com] Sent: Friday, October 28, 2011 2:19 AM To: UTTARO, JAMES Cc: robert@raszuk.net; idr@ietf.org List; Enke Chen Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 Jim, My comments are inlined. On 10/27/11 1:17 PM, UTTARO, JAMES wrote: Enke, GR is a solution that is essentially local in scope it does not have the ab= ility to inform downstream speakers of the viability of routing state from = the point of possible control plane failure. OTOH Persistence does propagat= e the condition of state. This provides distinct advantages in terms of cus= tomers awareness of the SPs control plane. One could imagine a customer rec= eiving a STALE path and responding by selecting a backup. Some of the exten= sions to this draft that I have considered in colouring of STALE to inform = if the condition arises from a local ( PE ) or internal iBGP ( RR ) failure= s.. GR makes no distinction from STALE state and ACTIVE state.. This can lead t= o the STALE path still being preferred throughout the topology. IMO this is= incorrect behavior regardless of the comparison. PERSISTENCE allows for a customer to indicate which paths should be candida= tes. Customers may want to immediately failover to the backup for some path= s and not for others. GR is not capable of doing this it is all or nothing.= The granularity is not sufficient. It needs to be at the path level. There= may even be a case for having even more granularity i.e a per path timer..= GR is not capable of being extended for either of these cases. I am not sure how this path level persistence would work operationally. W= ithout the detailed information of a provider's network, how would a custom= er know what kind of failures and recovery that they might experience? Co= nsider the example of the simultaneous RR failures in the draft, why would dn't any customer not to want to protect against such failures? The end r= esult could be that the PERSISTENCE flag is always set, thus losing its sig= nificance. [Jim U>] One ex would be customers who create multiple VPNs over different = SPs.. A customer may want to take advantage of the knowledge that a control= plane failure has occurred and migrate the traffic to the backup. This cou= ld be done at a path granularity by use of the DO_NOT_PERSIST CV. . We as S= Ps want to provide our customers with the tools needed to manage their VPNs= and not prescribe a one size fits all solution. Regarding the use of the STALE state vs ACTIVE state, clearly there is a tr= adeoff. GR uses the stale routes in order to avoid forwarding churns, whi= ch has been a critical requirement for a long time. If there is a real ne= ed for favoring a ACTIVE one over a STALE one in GR, it can be done by a si= mple knob. [Jim U>] The current draft has no ability to inform downstream speakers of = whether or not a path is STALE or ACTIVE. The knob may be simple but a lot = of machinery would have to be built. This is one of the big reasons for the= PERSIST draft. I do not understand the routing churn part in the context o= f vpnv4, vpnv2, 3107 etc... maybe the GR solution was constructed as a solu= tion that primarily speaks to eBGP IPV4 connections for the IPV4 AF ( Inter= net ).. I could understand that.. As you know, BGP is full of knobs that adjust behaviors for different needs= :-) [Jim U>] More Knobs.. GR does not provide protection through successive restarts of the session. = I believe that if this occurs the state will be invalidated. So for a sessi= on that is bouncing due to overload condition GR will not provide the requi= red protection This can be addressed by a simple knob to set the min stale timer for GR. [Jim U>] And yet more knobs GR does not employ a make before break strategy. All state is invalidated f= irst then the newly learned state is processed. This leads to routing churn= especially if the majority of the state is the same which I am pretty sure= is the case Such behavior would be an implementation bug that needs to be fixed. But i= t is not an issue with the protocol itself. This is what we have in 4.2. Procedures for the Receiving Speaker, RFC 4724= : --- The Receiving Speaker MUST replace the stale routes by the routing updates received from the peer. Once the End-of-RIB marker for an address family is received from the peer, it MUST immediately remove any routes from the peer that are still marked as stale for that address family. [Jim U>] This does not address the lack of clarity about make before break.= . it only states that must immediately remove routes marked as stale. It sh= ould state that any paths that are learned which are the same as the STALE = paths should not force the forwarding plane to be re-programmed for those p= aths.. This should be made clear and in general is good practice to avoid c= hurn.. There are several possibilities for the premature purge of the stale routes= . For example, the "Forwarding state" flag was somehow not set after the se= ssion was re-established, or the the EOR was sent prematurely. Further in= vestigation will be needed in order to identify any possible implementation= or config issues involved in your setup. [Jim U>] More moving parts to worry about.. GR invalidates state due to the case of protocol error i.e A malformed upda= te will invalidate all of the state. This is not the desired behavior. It has been addressed by the following extension: http://datatracker.ietf.org/doc/draft-keyupate-idr-bgp-gr-notification/ [Jim U>] A few comments here.. I do not understand, the draft does not clar= ify that the only thing that will force a tear down is the cease subcode an= d a hard reset error code.. is the intention that this is the only thing th= at will tear it down? I guess I would like to see which things will and wil= l not force a session termination in the original draft.. Like - Holdtime Expiration - Malformed Update - Consecutive Restarts.. So what does this exactly mean "As part= of this extension, possible consecutive restarts SHOULD NOT delete a route (from the peer) previously marked as stale, until required by rules mentioned in [RFC4724]." Possible consecutive restarts= means what? I really need clarity on this whole notion of when is a sessio= n truly invalidated. Why is the purpose of the following text? Once the session is re-established, both BGP speakers MUST set their "Forwarding State" bit to 1 if they want to apply planned graceful restart. The handling of the "Forwarding State" bit should be done as specified by the procedures of the Receiving speaker in [RFC4724] are applied. GR is not specific as to which events invoke it or not. From my read on the= draft it is not clear if holdtime expiration invokes GR or not.. The draft= is unclear. I think that it is covered by the above extension. If not, it should be cl= arified. [Jim U>] I did not see it.. It is not clear to me how RRs and PEs differ in using GR. I think that there is a main difference when a RR is not in the forwarding = path. In that case, the RR should always set the F bit in the GR Capabilit= y so that its clients will continue forwarding after they lose the sessions= with RR. It is a deployment issue, though. [Jim U>] Yes.. Again from an operations perspective I have to deploy techno= logy differently in different parts of the network across multiple vendors.= This is generally not a desired starting point for the successful deployme= nt of new technology.. I want solutions that are generic and simple to depl= oy. The time that state can persist is limit to about 1 hour max. I think that you are talking about the "Restart time" field which has 12 bi= ts and amount to about 68 minutes. The "Restart time" is for the session r= e-establishment. It does not impact the duration for holding stale routes = after the session is re-established. [Jim U>] But if the session does not become re-established then the state = is invalidated as the session terminates with an error code that GR will no= t persist through.. If the session does not get re-established in 68 minutes, the stale routes = would be purged. That is a long time, isn't it? However, if one really w= ants to extend the session re-establishment time and continue to hold stale= routes, it can be done by a simple knob. [Jim U>] And yet even more knobs GR does detail the behavior where convergence is not achieved between resta= rts.. Similar to above.. The min stale timer knob can cover it (see above). But do you meant "does not"? We can certainly clarify in 4724bis if that i= s the case. [Jim U>] If convergence is not achieved what is the behavior. I could not d= etermine from the draft.. I do not believe that the current GR paradigm can be extended to cover the = majority of the cases above. Except for the path level persistence you mentioned, I believe the GR will = be able to address all other persistence requirements you listed, with some= simple knobs and some implementation enhancements. [Jim U>] IMO GR was originally designed to prevent churn due to intermitten= t failure on an eBGP session for the IpV4 AF.. I do not want to have differ= ent knobs and implementation enhancements to solve the basics of persistenc= e.. Regardless of that it does not inform the topology of the state of a pa= th in re the control plane it was learned over so there can be no independe= nt decisions about the value of a given path by different customers/provide= rs.. This is required for my applications.. Thanks, Jim Uttaro Thanks. -- Enke -----Original Message----- From: Enke Chen [mailto:enkechen@cisco.com] Sent: Wednesday, October 26, 2011 8:43 PM To: UTTARO, JAMES Cc: robert@raszuk.net; idr@ietf.org List; Enke Chen Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 Hi, folks: I have a hard time in understanding what new problems (beyond the GR) the draft try to solve :-( If the concern is about the simultaneous RR failure as shown in the examples in Sect. 6 Application, that can be addressed easily using GR. As the RRs are not in the forwarding path, it means that the forwarding is not impacted (thus is preserved) during the restart of a RR. The Forwarding State bit (F) in the GR capability should always be set by the RR when it is not in the forwarding path. Also in the case of simultaneous RR failure, I do not see why one would want to retain some routes, but not others, using the communities specified in the draft. As the RRs are not in the forwarding path, wouldn't be better to retain all the routes on a PE/client? As you might be aware, efforts have been underway to address issues with GR found during implementation and deployment. They include the spec respin, notification handling, and implementations. If there are issues in the GR area that are not adequately addressed, I suggest that we try to address them in the GR respin if possible, instead of creating another variation unnecessarily. Thanks. -- Enke On 10/26/11 10:24 AM, Robert Raszuk wrote: Jim, When one during design phase of a routing protocol or routing protocol extension or modification to it already realizes that enabling such feature may cause real network issue if not done carefully - that should trigger the alarm to rethink the solution and explore alternative approaches to the problem space. We as operators have already hard time to relate enabling a feature within our intradomain boundaries to make sure such rollout is network wide. Here you are asking for the same level of awareness across ebgp boundaries. This is practically unrealistic IMHO. Back to the proposal ... I think that if anything needs to be done is to employ per prefix GR with longer and locally configurable timer. That would address information persistence across direct IBGP sessions. On the RRs use case of this draft we may perhaps agree to disagree, but I do not see large enough probability of correctly engineered RR plane to experience simultaneous multiple ibgp session drops. If that happens the RR placement, platforms or deployment model should be re-engineered. Summary .. I do not think that IDR WG should adopt this document. Just adding a warning to the deployment section is not sufficient. Best regards, R. Robert, The introduction of this technology needs to be carefully evaluated when being deployed into the network. Your example clearly calls out how a series of independent design can culminate in incorrect behavior. Certainly the deployment of persistence on a router that has interaction with a router that does not needs to be clearly understood by the network designer. The goal of this draft is to provide a fairly sophisticated tool that will protect the majority of customers in the event of a catastrophic failure.. The premise being the perfect is not the enemy of the good.. I will add text in the deployment considerations section to better articulate that.. Thanks, Jim Uttaro -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: Sunday, October 23, 2011 5:32 PM To: idr@ietf.org List= Subject: [Idr] draft-uttaro-idr-bgp-persistence-00 Authors, Actually when discussing this draft a new concern surfaced which I would like to get your answer on. The draft in section 4.2 says as one of the forwarding rules: o Forwarding to a "stale" route is only used if there are no other paths available to that route. In other words an active path always wins regardless of path selection. "Stale" state is always considered to be less preferred when compared with an active path. In the light of the above rule let's consider a very simple case of dual PE attached site of L3VPN service. Two CEs would inject into their IBGP mesh routes to the remote destination: one marked as STALE and one not marked at all. (Each CE is connected to different PE and each PE RT imports only a single route to a remote hub headquarter to support geographic load balancing). Let me illustrate: VPN Customer HUB PE3 PE4 SP PE1 PE2 | | | | CE1 CE2 | | 1| |10 | | R1 ------ R2 1 CE1,CE2,R1,R2 are in IBGP mesh. IGP metric of CE1-R1 and R1-R2 are 1 and R2-CE2 is 10. Prefix X is advertised by remote hub in the given VPN such that PE1 vrf towards CE1 only has X via PE3 and PE2's vrf towards CE2 only has X via PE4. Let's assume EBGP sessions PE3 to HUB went down, but ethernet link is up, next hop is in the RIB while data plane is gone. Assume no data plane real validation too. /* That is why in my former message I suggested that data plane validation would be necessary */. R1 has X via PE1/S (stale) and X via PE2/A (active) - it understands STALE so selects in his forwarding table path via CE2. R2 has X via PE1/S (stale) and X via PE2/A (active) - it does not understand STALE, never was upgraded to support the forwarding rule stated above in the draft and chooses X via CE1 (NH metric 2 vs 10). R1--R2 produce data plane loop as long as STALE paths are present in the system. Quite fun to troubleshoot too as the issue of PE3 injecting such STALE paths may be on the opposite site of the world. The issue occurs when some routers within the customer site will be able to recognize STALE transitive community and prefer non stale paths in their forwarding planes (or BGP planes for that matter) while others will not as well as when both stale and non stale paths will be present. Question 1: How do you prevent forwarding loop in such case ? Question 2: How do you prevent forwarding loop in the case when customer would have backup connectivity to his sites or connectivity via different VPN provider yet routers in his site only partially understand the STALE community and only partially follow the forwarding rules ? In general as the rule is about mandating some particular order of path forwarding selection what is the mechanism in distributed systems like today's routing to be able to achieve any assurance that such rule is active and enforced across _all_ routers behind EBGP PE-CE L3VPN boundaries in customer sites ? Best regards, R. -------- Original Message -------- Subject: [Idr] draft-uttaro-idr-bgp-persistence-00 Date: Sat, 22 Oct 2011 00:23:55 +0200 From: Robert Raszuk Repl= y-To: robert@raszuk.net To: idr@ietf.org List Hi, I have read the draft and have one question and one observation. Question: What is the point of defining DO_NOT_PERSIST community ? In other words why not having PERSIST community set would not mean the same as having path marked with DO_NOT_PERSIST. Observation: I found the below statement in section 4.2: o Forwarding must ensure that the Next Hop to a "stale" route is viable. Of course I agree. But since we stating obvious in the forwarding section I think it would be good to explicitly also state this in the best path selection that next hop to STALE best path must be valid. However sessions especially those between loopbacks do not go down for no reason. Most likely there is network problem which may have caused those sessions to go down. It is therefor likely that LDP session went also down between any of the LSRs in the data path and that in spite of having the paths in BGP and next hops in IGP the LSP required for both quoted L2/L3VPN applications is broken. That may particularly happen when network chooses to use independent control mode for label allocation. I would suggest to at least add the recommendation statement to the document that during best path selection especially for stale paths a validity of required forwarding paradigm to next hop of stale paths should be verified. For example using techniques as described in: draft-ietf-idr-bgp-bestpath-selection-criteria Best regards, R. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_B17A6910EEDD1F45980687268941550FA324FAMISOUT7MSGUSR9IIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

          =       First let me apologize for not being able to= attend the ietf..

 

          =       After watching jabber it seems that the pres= entation of persistence degraded to something in re how we can apply multip= le Band-Aids, patches, knobs etc… to extend GR to cover the Persistence draft.. IMO GR is a= subset of the Persistence functionality and may be therefore subsumed into= the Persistence draft. Philosophically GR makes the session the invariant = and all behavior that follows is based upon this premise.. As stated in the slides, many of the new services have= much looser association between the control and forwarding planes i.e L2VN= , L3VPN, 3107 etc…

 

 Again let me clarify, when I looked at GR earlier this= year it became clear that the basic philosophy, and rules stating when to = persist, how long, triggers to stop would not meet the requirements I have.. From a philosophical poin= t GR assumes that the paths that are persisting in forwarding should mainta= in their preference throughout the routing topology. Why? This seems beyond= prescriptive as it does not provide the network operators with any flexibility as to how state learned  o= ver a compromised control may be viewed/used by the downstream routing topo= logy including customers. From my reading of the draft there is no way to a= llow operators to persist, not-persist, or de pref the state (stale). Do I have this wrong?  I do not think s= o.. So if we want to incorporate this ability into GR it would require a ba= sic philosophical change.. of course even if this is done there is no way f= or a peer to pre-program  paths it has advertised to be treated if there is a failure.. So, even if we perform ma= jor surgery there is still no way to accomplish this beyond unique filters = and maybe CVs.. WE could call them STALE, PERSIST and DO_NOT_PERSIST and th= en build routing policy across all of our BGP speakers.. Then we can spends lots of time making sure that thi= s bottom approach is consistent across the entire topology, and coordinate = with customers also..

 

As I mentioned in a previous note ( see below ) GR does not = meet requirements in terms of triggers that terminate GR persistence, timer= s etc…  personally I am not that interested in  a solution that fundamentally does not m= eet my requirements.. Most of the responses I have received is that GR can = be extended. I do not think it can ever meet the requirements above and wil= l require major surgery to fix the triggers, timers etc.. So the approach should be to fold the subset of GR functional= ity into the larger Persistence draft..

 

Jim Uttaro

 

 

Enke,

 

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

 

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

 

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

 

GR does not provide protection through successive restart= s of the session. I believe that if this occurs the state will be invalidat= ed. So for a session that is bouncing due to overload condition GR will not provide the required protec= tion

 

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

 

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

 

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

 

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

 

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

 

GR does detail the behavior where convergence is not achi= eved between restarts.. Similar to above.. 

 

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

 

Thanks,

        Jim Uttaro

 

 

From: UTTARO, JAMES
Sent: Tuesday, November 01, 2011 11:20 AM
To: 'Enke Chen'
Cc: robert@raszuk.net; idr@ietf.org List
Subject: RE: [Idr] draft-uttaro-idr-bgp-persistence-00

 

Enke,

 

          =       Comments in-Line..

 

Thanks,

          =       Jim Uttaro

 

From: Enke Chen [mai= lto:enkechen@cisco.com]
Sent: Friday, October 28, 2011 2:19 AM
To: UTTARO, JAMES
Cc: robert@raszuk.net; idr@ietf.org List; Enke Chen
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00

 

Jim,

My comments are inlined.

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

Enke,
 
GR is a solution that is essentially local in scope it does not have t=
he ability to inform downstream speakers of the viability of routing state =
from the point of possible control plane failure. OTOH Persistence does pro=
pagate the condition of state. This provides distinct advantages in terms o=
f customers awareness of the SPs control plane. One could imagine a custome=
r receiving a STALE path and responding by selecting a backup. Some of the =
extensions to this draft that I have considered in colouring of STALE to in=
form if the condition arises from a local ( PE ) or internal iBGP ( RR ) fa=
ilures.. 
 
GR makes no distinction from STALE state and ACTIVE state.. This can l=
ead to the STALE path still being preferred throughout the topology. IMO th=
is is incorrect behavior regardless of the comparison. 
 
PERSISTENCE allows for a customer to indicate which paths should be ca=
ndidates. Customers may want to immediately failover to the backup for some=
 paths and not for others. GR is not capable of doing this it is all or not=
hing. The granularity is not sufficient. It needs to be at the path level. =
There may even be a case for having even more granularity i.e a per path ti=
mer.. GR is not capable of being extended for either of these cases.


I am not sure how this path level persistence would work operationally.&nbs= p;  Without the detailed information of a provider's network, how woul= d a customer know what kind of failures and recovery that they might experi= ence?   Consider the example of the simultaneous RR failures in the draft,  why would

dn't any customer not to want to protect against suc= h failures?   The end result could be that the PERSISTENCE flag i= s always set, thus losing its significance.

[Jim U>] One ex would be customers who create multiple VP= Ns over different SPs.. A customer may want to take advantage of the knowle= dge that a control plane failure has occurred and migrate the traffic to the backup. This cou= ld be done at a path granularity by use of the DO_NOT_PERSIST CV. . We as S= Ps want to provide our customers with the tools needed to manage their VPNs= and not prescribe a one size fits all solution.



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

[Jim U>] The current draft has no ability to inform downs= tream speakers of whether or not a path is STALE or ACTIVE. The knob may be= simple but a lot of machinery would have to be built. This is one of the big reasons for th= e PERSIST draft. I do not understand the routing churn part in the context = of vpnv4, vpnv2, 3107 etc… maybe the GR solution was constructed as a= solution that primarily speaks to eBGP IPV4 connections for the IPV4 AF ( Internet ).. I could understand that..<= o:p>



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

[Jim U>] More Knobs..



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


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

[Jim U>] And yet more knobs



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


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

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

---

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

[Jim U>] This does not address the lack of clarity about = make before break.. it only states that must immediately remove routes mark= ed as stale. It should state that any paths that are learned which are the same as the STA= LE paths should not force the forwarding plane to be re-programmed for thos= e paths.. This should be made clear and in general is good practice to avoi= d churn..



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

[Jim U>] More moving parts to worry about..



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


It has been addressed by the following extension:

http://datatracker.ietf.org/doc/draft-keyupate-idr-bgp-gr-notifica= tion/

[Jim U>] A few comments here.. I do not understand, the d= raft does not clarify that the only thing that will force a tear down is th= e cease subcode and a hard reset error code.. is the intention that this is the only thing= that will tear it down? I guess I would like to see which things will and = will not force a session termination in the original draft.. Like

 

- =          Holdtime Expiration

- =          Malformed Update

=
-    &nbs=
p;     Consecutive Restarts.. So what does this exactly mean   “As part of this extension, =
possible consecutive restarts SHOULD NOT

   delete a route (from the peer) previously ma= rked as stale, until

   required by rules mentioned in [RFC4724].= 221; Possible consecutive restarts means what? I really need clar= ity on this whole notion of when is a session truly invalidated.=

 

Why is the purpose of the following text?<= /p>

 

   Once the session is re-established, both BGP= speakers MUST set their

   "Forwarding State" bit to 1 if the= y want to apply planned graceful

   restart.  The handling of the "For= warding State" bit should be done

   as specified by the procedures of the Receiv= ing speaker in [RFC4724]

   are applied.

 

 

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


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

[Jim U>] I did not see it..



 
It is not clear to me how RRs and PEs differ in using GR. <=
/pre>



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


[Jim U>] Yes.. Again from an operations perspective I hav=
e to deploy technology differently in different parts of the network across=
 multiple vendors.
 This is generally not a desired starting point for the successful deployme=
nt of new technology.. I want solutions that are generic and simple to depl=
oy.










 


 


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




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


[Jim U>]  But if the session does not become re-esta=
blished then the state is invalidated as the session terminates with an err=
or code that GR will
 not persist through..






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


[Jim U>] And yet even more knobs









 


 


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




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



But do you meant "does not"?  We can certainly clarify in 47=
24bis if that is the case.<=
/p>

[Jim U>] If convergence is not achieved what is the behav=
ior. I could not determine from the draft..









 


 


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




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



[Jim U>] IMO GR was originally designed to prevent churn =
due to intermittent failure on an eBGP session for the IpV4 AF.. I do not w=
ant to have different
 knobs and implementation enhancements to solve the basics of persistence..=
 Regardless of that it does not inform the topology of the state of a path =
in re the control plane it was learned over so there can be no independent =
decisions about the value of a given
 path by different customers/providers.. This is required for my applicatio=
ns.. 










 


 


Thanks,


        Jim Uttaro




Thanks.   -- Enke






 


 


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


From: Enke Chen [mailto:enkechen=
@cisco.com] 


Sent: Wednesday, October 26, 2011 8:43 PM


To: UTTARO, JAMES


Cc: robert@raszuk.net; idr@ietf.org List; Enke Chen


Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00

 


Hi, folks:


 


I have a hard time in understanding what new problems (beyond the GR) =



the draft try to solve :-(


 


If the concern is about the simultaneous RR failure as shown in the 


examples in Sect. 6 Application, that can be addressed easily using GR=
.  


As the RRs are not in the forwarding path, it means that the forwardin=
g 


is not impacted (thus is preserved) during the restart of a RR. &=
nbsp; The 


Forwarding State bit (F) in the GR capability should always be set by =



the RR when it is not in the forwarding path.


 


Also in the case of simultaneous RR failure, I do not see why one woul=
d 


want to retain some routes, but not others, using the communities 


specified in the draft.  As the RRs are not in the forwarding pat=
h, 


wouldn't be better to retain all the routes on a PE/client?=



 


As you might be aware, efforts have been underway to address issues wi=
th 


GR found during implementation and deployment. They include the spec <=
o:p>


respin, notification handling, and implementations.  If there are=
 issues 


in the GR area that are not adequately addressed,  I suggest that=
 we try 


to address them in the GR respin if possible, instead of creating 


another variation unnecessarily.


 


Thanks.   -- Enke


 


 


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




Jim,


 


When one during design phase of a routing protocol or routing protocol=
 


extension or modification to it already realizes that enabling such 


feature may cause real network issue if not done carefully - that 


should trigger the alarm to rethink the solution and explore 


alternative approaches to the problem space.


 


We as operators have already hard time to relate enabling a feature 


within our intradomain boundaries to make sure such rollout is network=
 


wide. Here you are asking for the same level of awareness across ebgp =



boundaries. This is practically unrealistic IMHO.


 


Back to the proposal ... I think that if anything needs to be done is =



to employ per prefix GR with longer and locally configurable timer. 


That would address information persistence across direct IBGP sessions=
.


 


On the RRs use case of this draft we may perhaps agree to disagree, 


but I do not see large enough probability of correctly engineered RR <=
o:p>


plane to experience simultaneous multiple ibgp session drops. If that =



happens the RR placement, platforms or deployment model should be 


re-engineered.


 


Summary .. I do not think that IDR WG should adopt this document. Just=
 


adding a warning to the deployment section is not sufficient.


 


Best regards,


R.


 


 




Robert,


 


The introduction of this technology needs to be carefully evaluated


when being deployed into the network. Your example clearly calls out


how a series of independent design can culminate in incorrect


behavior. Certainly the deployment of persistence on a router that


has interaction with a router that does not needs to be clearly


understood by the network designer. The goal of this draft is to<=
/o:p>


provide a fairly sophisticated tool that will protect the majority of<=
o:p>


customers in the event of a catastrophic failure.. The premise being


the perfect is not the enemy of the good.. I will add text in the=



deployment considerations section to better articulate that..


 


Thanks, Jim Uttaro


 


-----Original Message----- From: idr-bounces@ietf.org


[mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent:


Sunday, October 23, 2011 5:32 PM To: i=
dr@ietf.org List Subject: [Idr]


draft-uttaro-idr-bgp-persistence-00


 


Authors,


 


Actually when discussing this draft a new concern surfaced which I


would like to get your answer on.


 


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


 


o  Forwarding to a "stale" route is only used if there =
are no other


paths available to that route.  In other words an active path alw=
ays


wins regardless of path selection.  "Stale" state is al=
ways


considered to be less preferred when compared with an active path.


 


In the light of the above rule let's consider a very simple case of


dual PE attached site of L3VPN service. Two CEs would inject into=



their IBGP mesh routes to the remote destination: one marked as STALE<=
o:p>


and  one not marked at all. (Each CE is connected to different PE=
 and


each PE RT imports only a single route to a remote hub headquarter to<=
o:p>


support geographic load balancing).


 


Let me illustrate:


 


VPN Customer HUB


 


PE3      PE4 SP PE1    &n=
bsp; PE2 |        | |   &=
nbsp;    | CE1      CE2 |


| 1|        |10 |   =
     | R1 ------ R2 1


 


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


and R2-CE2 is 10.


 


Prefix X is advertised by remote hub in the given VPN such that PE1


vrf towards CE1 only has X via PE3 and PE2's vrf towards CE2 only has<=
o:p>


X via PE4.


 


Let's assume EBGP sessions PE3 to HUB went down, but ethernet link


is up, next hop is in the RIB while data plane is gone. Assume no=



data plane real validation too. /* That is why in my former message


I suggested that data plane validation would be necessary */.


 


R1 has X via PE1/S (stale) and X via PE2/A (active) - it understands


STALE so selects in his forwarding table path via CE2.

 


R2 has X via PE1/S (stale) and X via PE2/A (active) - it does not=



understand STALE, never was upgraded to support the forwarding rule


stated above in the draft and chooses X via CE1 (NH metric 2 vs 10).


 


R1--R2 produce data plane loop as long as STALE paths are present in


the system. Quite fun to troubleshoot too as the issue of PE3


injecting such STALE paths may be on the opposite site of the world.


 


The issue occurs when some routers within the customer site will be


able to recognize STALE transitive community and prefer non stale=



paths in their forwarding planes (or BGP planes for that matter)<=
/o:p>


while others will not as well as when both stale and non stale paths


will be present.


 


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


 


Question 2: How do you prevent forwarding loop in the case when


customer would have backup connectivity to his sites or connectivity


via different VPN provider yet routers in his site only partially=



understand the STALE community and only partially follow the


forwarding rules ?


 


In general as the rule is about mandating some particular order of


path forwarding selection what is the mechanism in distributed


systems like today's routing to be able to achieve any assurance that<=
o:p>


such rule is active and enforced across _all_ routers behind EBGP=



PE-CE L3VPN boundaries in customer sites ?


 


Best regards, R.


 


 


-------- Original Message -------- Subject: [Idr]


draft-uttaro-idr-bgp-persistence-00 Date: Sat, 22 Oct 2011 00:23:55


+0200 From: Robert Raszuk<=
robert@raszuk.net> Reply-To:


robert@raszuk.net To: idr@ietf.org List<idr@ietf.org>


 


Hi,


 


I have read the draft and have one question and one observation.<=
/o:p>


 


Question:


 


What is the point of defining DO_NOT_PERSIST community ? In other=



words why not having PERSIST community set would not mean the same as<=
o:p>


having path marked with DO_NOT_PERSIST.


 


Observation:


 


I found the below statement in section 4.2:


 


o  Forwarding must ensure that the Next Hop to a "stale"=
; route is


viable.


 


Of course I agree. But since we stating obvious in the forwarding=



section I think it would be good to explicitly also state this in=



the best path selection that next hop to STALE best path must be<=
/o:p>


valid.


 


However sessions especially those between loopbacks do not go down


for no reason. Most likely there is network problem which may have


caused those sessions to go down. It is therefor likely that LDP<=
/o:p>


session went also down between any of the LSRs in the data path and


that in spite of having the paths in BGP and next hops in IGP the LSP<=
o:p>


required for both quoted L2/L3VPN applications is broken. That may


particularly happen when network chooses to use independent control


mode for label allocation.


 


I would suggest to at least add the recommendation statement to the


document that during best path selection especially for stale paths


a validity of required forwarding paradigm to next hop of stale


paths should be verified.


 


For example using techniques as described in:


draft-ietf-idr-bgp-bestpath-selection-criteria


 


Best regards, R.


 


 


_______________________________________________ Idr mailing list<=
/o:p>


Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr<=
/a>


 


 


_______________________________________________ Idr mailing list<=
/o:p>


Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr<=
/a>


 


 




 


_______________________________________________


Idr mailing list


Idr@ietf.org


https://www.ietf=
.org/mailman/listinfo/idr




 


 
--_000_B17A6910EEDD1F45980687268941550FA324FAMISOUT7MSGUSR9IIT_-- From wwwrun@rfc-editor.org Mon Nov 14 17:48:05 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45D611E8106 for ; Mon, 14 Nov 2011 17:48:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfUpoHxeOejt for ; Mon, 14 Nov 2011 17:48:05 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 5204711E80CC for ; Mon, 14 Nov 2011 17:48:04 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 15093B1E003; Mon, 14 Nov 2011 17:42:56 -0800 (PST) To: yakov@juniper.net, tony.li@tony.li, skh@nexthop.com, stbryant@cisco.com, adrian@olddog.co.uk, shares@ndzh.com, jgs@juniper.net From: RFC Errata System Message-Id: <20111115014256.15093B1E003@rfc-editor.org> Date: Mon, 14 Nov 2011 17:42:56 -0800 (PST) X-Mailman-Approved-At: Mon, 14 Nov 2011 22:03:05 -0800 Cc: kireeti@juniper.net, idr@ietf.org, rfc-editor@rfc-editor.org Subject: [Idr] [Editorial Errata Reported] RFC4271 (3031) 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, 15 Nov 2011 01:48:05 -0000 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=3031 -------------------------------------- Type: Editorial Reported by: Kireeti Kompella Section: 9.1.2 Original Text ------------- The Phase 2 decision function is blocked from running while the Phase 3 decision function is in process. Corrected Text -------------- The Phase 3 decision function is blocked from running while the Phase 2 decision function is in process. Notes ----- I believe that is what was intended; the text as is confuses me no end. 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 jgs@juniper.net Mon Nov 14 22:31:24 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7291F0CBB for ; Mon, 14 Nov 2011 22:31:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vLD3DFSvsWy for ; Mon, 14 Nov 2011 22:31:24 -0800 (PST) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id ADCE41F0C5B for ; Mon, 14 Nov 2011 22:31:20 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKTsIHOPYfOFNaRaxeWa3bdQSpX8+lRohB@postini.com; Mon, 14 Nov 2011 22:31:23 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 14 Nov 2011 22:28:04 -0800 From: John Scudder To: "idr@ietf.org List" Date: Mon, 14 Nov 2011 22:28:06 -0800 Thread-Topic: draft minutes posted Thread-Index: AcyjX7r0PdAXgU99T9WwPwtdjgUhpw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Idr] draft minutes 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, 15 Nov 2011 06:31:24 -0000 Folks, In an effort at timeliness, draft minutes of today's meeting are posted: http://www.ietf.org/proceedings/82/minutes/idr.txt They are very, very, draft -- from my edit buffer to your ears. Feel free = to send any comments or corrections; however you may want to wait until the= chairs have gone one round of revision on them before spending your time o= n this. We'll update the list when they are cleaned up a little. Thanks, --John= From stbryant@cisco.com Mon Nov 14 22:40:49 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF6511E82FA for ; Mon, 14 Nov 2011 22:40:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.209 X-Spam-Level: X-Spam-Status: No, score=-109.209 tagged_above=-999 required=5 tests=[AWL=1.389, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYVDo30GpiuN for ; Mon, 14 Nov 2011 22:40:49 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id D520611E82F9 for ; Mon, 14 Nov 2011 22:40:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=2892; q=dns/txt; s=iport; t=1321339249; x=1322548849; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=W6pAWtG6QMwmi/p4MG26Ash98yrB7fjBs5jsCdAUBcE=; b=cf+vylKD3CzaAzEDcDkFwfYI+9ZFM45MNOZAnTWkR+Qj0fZYpLdGfRzm K6tANau2ibB8E+yU8K6RwPsKJ61ZKt508eMXXVReqfDCnVxEgB88NgwZq OfQlP5s3RD7rmn3LQe1jg+dqqXeLp/0dUf4T8bDAcQcYpaiRIWTV9R9ER 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACkIwk6Q/khL/2dsb2JhbABEqWmBBYFyAQEBBAEBAQ8BAgFYCgEQCwQKCgkWDwkDAgECARUwBg0BBQIBAQUZh2icTQGDLg8Bm0WKBASUMJF6 X-IronPort-AV: E=Sophos;i="4.69,513,1315180800"; d="scan'208,217";a="121613798" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 15 Nov 2011 06:40:46 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pAF6ekwp016608; Tue, 15 Nov 2011 06:40:46 GMT Received: from dhcp-563c.meeting.ietf.org (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id pAF6egfs023650; Tue, 15 Nov 2011 06:40:44 GMT Message-ID: <4EC2096A.1040309@cisco.com> Date: Tue, 15 Nov 2011 06:40:42 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: John Scudder References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020305020803040403010703" Cc: "idr@ietf.org List" Subject: Re: [Idr] draft minutes posted 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: Tue, 15 Nov 2011 06:40:49 -0000 This is a multi-part message in MIME format. --------------020305020803040403010703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 15/11/2011 06:28, John Scudder wrote: > Folks, > > In an effort at timeliness, draft minutes of today's meeting are posted: > > http://www.ietf.org/proceedings/82/minutes/idr.txt > > They are very, very, draft -- from my edit buffer to your ears. Feel free to send any comments or corrections; however you may want to wait until the chairs have gone one round of revision on them before spending your time on this. We'll update the list when they are cleaned up a little. > > Thanks, > > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > We should note that there was consensus to resume the publication of draft-ietf-idr-deprecate-as-sets as a BCP; then Danny said " Danny: please don't forget to do the deprecation step!", and the chairs agreed that they would not forget the followup step. Stewart --------------020305020803040403010703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 15/11/2011 06:28, John Scudder wrote: 
Folks,

In an effort at timeliness, draft minutes of today's meeting are posted:

http://www.ietf.org/proceedings/82/minutes/idr.txt

They are very, very, draft -- from my edit buffer to your ears.  Feel free to send any comments or corrections; however you may want to wait until the chairs have gone one round of revision on them before spending your time on this.  We'll update the list when they are cleaned up a little.

Thanks,

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

We should note that there was consensus to resume the publication of
draft-ietf-idr-deprecate-as-sets as a BCP; then Danny said
" Danny: please don't forget to do the deprecation step!", and the
chairs agreed that they would not forget the followup step.

Stewart
--------------020305020803040403010703-- From robert@raszuk.net Mon Nov 14 23:10:57 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 654431F0C3B for ; Mon, 14 Nov 2011 23:10:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[AWL=1.398, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5eTWSS-mtCn for ; Mon, 14 Nov 2011 23:10:51 -0800 (PST) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA1A11E8094 for ; Mon, 14 Nov 2011 23:10:29 -0800 (PST) Received: (qmail 29393 invoked by uid 399); 15 Nov 2011 07:10:27 -0000 Received: from unknown (HELO ?10.0.1.3?) (130.129.67.115) by mail1310.opentransfer.com with ESMTP; 15 Nov 2011 07:10:27 -0000 X-Originating-IP: 130.129.67.115 Message-ID: <4EC21062.5020504@raszuk.net> Date: Tue, 15 Nov 2011 08:10:26 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "UTTARO, JAMES" References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net> <4EA84254.9000400@raszuk.net> <4EA8A91C.4090305@cisco.com> <4EAA496C.9070605@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'idr@ietf.org List'" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 07:10:58 -0000 Hi Jim, You are correct that GR does not allow to propagate information by default on what paths should be called as "suspicious". However as mentioned at the mic during the session we need to have a way to modify best path selection criteria universally as opposed to continue to invent new tools to solve point problems and punch holes in the various implementations of BGP best path selection. Chairs in fact responded that we will work on this when the right time comes. Back to the persistence draft ... GR can address 90% of the persistence draft requirements. Propagating information about "suspicious" paths if at all we all agree if this is a good idea can be done today with either setting lowest local pref, using cost community or marking with community so your ebgp peers can interpret it correctly. Why do we need new way to signal this ? Also I think current -00 version has serious issues as already pointed on the list. We need to wait till -01 is published in order to see if those issues have been fixed. Best regards, R. > All, > > First let me apologize for not being able to attend the ietf.. > > After watching jabber it seems that the presentation of persistence > degraded to something in re how we can apply multiple Band-Aids, > patches, knobs etc... to extend GR to cover the Persistence draft.. > IMO GR is a subset of the Persistence functionality and may be > therefore subsumed into the Persistence draft. Philosophically GR > makes the session the invariant and all behavior that follows is > based upon this premise.. As stated in the slides, many of the new > services have much looser association between the control and > forwarding planes i.e L2VN, L3VPN, 3107 etc... > > Again let me clarify, when I looked at GR earlier this year it became > clear that the basic philosophy, and rules stating when to persist, > how long, triggers to stop would not meet the requirements I have.. > From a philosophical point GR assumes that the paths that are > persisting in forwarding should maintain their preference throughout > the routing topology. Why? This seems beyond prescriptive as it does > not provide the network operators with any flexibility as to how > state learned over a compromised control may be viewed/used by the > downstream routing topology including customers. From my reading of > the draft there is no way to allow operators to persist, not-persist, > or de pref the state (stale). Do I have this wrong? I do not think > so.. So if we want to incorporate this ability into GR it would > require a basic philosophical change.. of course even if this is done > there is no way for a peer to pre-program paths it has advertised to > be treated if there is a failure.. So, even if we perform major > surgery there is still no way to accomplish this beyond unique > filters and maybe CVs.. WE could call them STALE, PERSIST and > DO_NOT_PERSIST and then build routing policy across all of our BGP > speakers.. Then we can spends lots of time making sure that this > bottom approach is consistent across the entire topology, and > coordinate with customers also.. > > As I mentioned in a previous note ( see below ) GR does not meet > requirements in terms of triggers that terminate GR persistence, > timers etc... personally I am not that interested in a solution > that fundamentally does not meet my requirements.. Most of the > responses I have received is that GR can be extended. I do not think > it can ever meet the requirements above and will require major > surgery to fix the triggers, timers etc.. So the approach should be > to fold the subset of GR functionality into the larger Persistence > draft.. > > Jim Uttaro > > > Enke, > > GR is a solution that is essentially local in scope it does not have > the ability to inform downstream speakers of the viability of routing > state from the point of possible control plane failure. OTOH > Persistence does propagate the condition of state. This provides > distinct advantages in terms of customers awareness of the SPs > control plane. One could imagine a customer receiving a STALE path > and responding by selecting a backup. Some of the extensions to this > draft that I have considered in colouring of STALE to inform if the > condition arises from a local ( PE ) or internal iBGP ( RR ) > failures.. > > GR makes no distinction from STALE state and ACTIVE state.. This can > lead to the STALE path still being preferred throughout the topology. > IMO this is incorrect behavior regardless of the comparison. > > PERSISTENCE allows for a customer to indicate which paths should be > candidates. Customers may want to immediately failover to the backup > for some paths and not for others. GR is not capable of doing this it > is all or nothing. The granularity is not sufficient. It needs to be > at the path level. There may even be a case for having even more > granularity i.e a per path timer.. GR is not capable of being > extended for either of these cases. > > GR does not provide protection through successive restarts of the > session. I believe that if this occurs the state will be invalidated. > So for a session that is bouncing due to overload condition GR will > not provide the required protection > > GR does not employ a make before break strategy. All state is > invalidated first then the newly learned state is processed. This > leads to routing churn especially if the majority of the state is the > same which I am pretty sure is the case > > GR invalidates state due to the case of protocol error i.e A > malformed update will invalidate all of the state. This is not the > desired behavior. > > GR is not specific as to which events invoke it or not. From my read > on the draft it is not clear if holdtime expiration invokes GR or > not.. The draft is unclear. > > It is not clear to me how RRs and PEs differ in using GR. > > The time that state can persist is limit to about 1 hour max. > > GR does detail the behavior where convergence is not achieved between > restarts.. Similar to above.. > > I do not believe that the current GR paradigm can be extended to > cover the majority of the cases above. > > Thanks, Jim Uttaro > > > From: UTTARO, JAMES Sent: Tuesday, November 01, 2011 11:20 AM To: > 'Enke Chen' Cc: robert@raszuk.net; idr@ietf.org List Subject: RE: > [Idr] draft-uttaro-idr-bgp-persistence-00 > > Enke, > > Comments in-Line.. > > Thanks, Jim Uttaro > > From: Enke Chen [mailto:enkechen@cisco.com] Sent: Friday, October 28, > 2011 2:19 AM To: UTTARO, JAMES Cc: robert@raszuk.net; idr@ietf.org > List; Enke Chen Subject: Re: [Idr] > draft-uttaro-idr-bgp-persistence-00 > > Jim, > > My comments are inlined. > > On 10/27/11 1:17 PM, UTTARO, JAMES wrote: > > Enke, > > > > GR is a solution that is essentially local in scope it does not have > the ability to inform downstream speakers of the viability of routing > state from the point of possible control plane failure. OTOH > Persistence does propagate the condition of state. This provides > distinct advantages in terms of customers awareness of the SPs > control plane. One could imagine a customer receiving a STALE path > and responding by selecting a backup. Some of the extensions to this > draft that I have considered in colouring of STALE to inform if the > condition arises from a local ( PE ) or internal iBGP ( RR ) > failures.. > > > > GR makes no distinction from STALE state and ACTIVE state.. This can > lead to the STALE path still being preferred throughout the topology. > IMO this is incorrect behavior regardless of the comparison. > > > > PERSISTENCE allows for a customer to indicate which paths should be > candidates. Customers may want to immediately failover to the backup > for some paths and not for others. GR is not capable of doing this it > is all or nothing. The granularity is not sufficient. It needs to be > at the path level. There may even be a case for having even more > granularity i.e a per path timer.. GR is not capable of being > extended for either of these cases. > > I am not sure how this path level persistence would work > operationally. Without the detailed information of a provider's > network, how would a customer know what kind of failures and recovery > that they might experience? Consider the example of the > simultaneous RR failures in the draft, why would dn't any customer > not to want to protect against such failures? The end result could > be that the PERSISTENCE flag is always set, thus losing its > significance. [Jim U>] One ex would be customers who create multiple > VPNs over different SPs.. A customer may want to take advantage of > the knowledge that a control plane failure has occurred and migrate > the traffic to the backup. This could be done at a path granularity > by use of the DO_NOT_PERSIST CV. . We as SPs want to provide our > customers with the tools needed to manage their VPNs and not > prescribe a one size fits all solution. > > > Regarding the use of the STALE state vs ACTIVE state, clearly there > is a tradeoff. GR uses the stale routes in order to avoid > forwarding churns, which has been a critical requirement for a long > time. If there is a real need for favoring a ACTIVE one over a > STALE one in GR, it can be done by a simple knob. [Jim U>] The > current draft has no ability to inform downstream speakers of whether > or not a path is STALE or ACTIVE. The knob may be simple but a lot of > machinery would have to be built. This is one of the big reasons for > the PERSIST draft. I do not understand the routing churn part in the > context of vpnv4, vpnv2, 3107 etc... maybe the GR solution was > constructed as a solution that primarily speaks to eBGP IPV4 > connections for the IPV4 AF ( Internet ).. I could understand that.. > > > As you know, BGP is full of knobs that adjust behaviors for different > needs :-) [Jim U>] More Knobs.. > > > > > > > > GR does not provide protection through successive restarts of the > session. I believe that if this occurs the state will be invalidated. > So for a session that is bouncing due to overload condition GR will > not provide the required protection > > This can be addressed by a simple knob to set the min stale timer for > GR. [Jim U>] And yet more knobs > > > > > > > > GR does not employ a make before break strategy. All state is > invalidated first then the newly learned state is processed. This > leads to routing churn especially if the majority of the state is the > same which I am pretty sure is the case > > Such behavior would be an implementation bug that needs to be fixed. > But it is not an issue with the protocol itself. > > This is what we have in 4.2. Procedures for the Receiving Speaker, > RFC 4724: > > --- > > The Receiving Speaker MUST replace the stale routes by the routing > > updates received from the peer. Once the End-of-RIB marker for an > > address family is received from the peer, it MUST immediately remove > > any routes from the peer that are still marked as stale for that > > address family. [Jim U>] This does not address the lack of clarity > about make before break.. it only states that must immediately remove > routes marked as stale. It should state that any paths that are > learned which are the same as the STALE paths should not force the > forwarding plane to be re-programmed for those paths.. This should be > made clear and in general is good practice to avoid churn.. > > > There are several possibilities for the premature purge of the stale > routes. For example, the "Forwarding state" flag was somehow not set > after the session was re-established, or the the EOR was sent > prematurely. Further investigation will be needed in order to > identify any possible implementation or config issues involved in > your setup. [Jim U>] More moving parts to worry about.. > > > > > > > > GR invalidates state due to the case of protocol error i.e A > malformed update will invalidate all of the state. This is not the > desired behavior. > > It has been addressed by the following extension: > > http://datatracker.ietf.org/doc/draft-keyupate-idr-bgp-gr-notification/ > > [Jim U>] A few comments here.. I do not understand, the draft does > not clarify that the only thing that will force a tear down is the > cease subcode and a hard reset error code.. is the intention that > this is the only thing that will tear it down? I guess I would like > to see which things will and will not force a session termination in > the original draft.. Like > > > - Holdtime Expiration > > - Malformed Update > > - Consecutive Restarts.. So what does this exactly mean > "As part of this extension, possible consecutive restarts SHOULD NOT > delete a route (from the peer) previously marked as stale, until > required by rules mentioned in [RFC4724]." Possible consecutive > restarts means what? I really need clarity on this whole notion of > when is a session truly invalidated. > > Why is the purpose of the following text? > > Once the session is re-established, both BGP speakers MUST set their > "Forwarding State" bit to 1 if they want to apply planned graceful > restart. The handling of the "Forwarding State" bit should be done > as specified by the procedures of the Receiving speaker in [RFC4724] > are applied. > > > > > > > > GR is not specific as to which events invoke it or not. From my read > on the draft it is not clear if holdtime expiration invokes GR or > not.. The draft is unclear. > > I think that it is covered by the above extension. If not, it should > be clarified. [Jim U>] I did not see it.. > > > > > > It is not clear to me how RRs and PEs differ in using GR. > > I think that there is a main difference when a RR is not in the > forwarding path. In that case, the RR should always set the F bit in > the GR Capability so that its clients will continue forwarding after > they lose the sessions with RR. It is a deployment issue, though. > [Jim U>] Yes.. Again from an operations perspective I have to deploy > technology differently in different parts of the network across > multiple vendors. This is generally not a desired starting point for > the successful deployment of new technology.. I want solutions that > are generic and simple to deploy. > > > > > > > > The time that state can persist is limit to about 1 hour max. > > I think that you are talking about the "Restart time" field which has > 12 bits and amount to about 68 minutes. The "Restart time" is for > the session re-establishment. It does not impact the duration for > holding stale routes after the session is re-established. [Jim U>] > But if the session does not become re-established then the state is > invalidated as the session terminates with an error code that GR will > not persist through.. > > > If the session does not get re-established in 68 minutes, the stale > routes would be purged. That is a long time, isn't it? However, if > one really wants to extend the session re-establishment time and > continue to hold stale routes, it can be done by a simple knob. [Jim > U>] And yet even more knobs > > > > > > > > GR does detail the behavior where convergence is not achieved between > restarts.. Similar to above.. > > The min stale timer knob can cover it (see above). > > But do you meant "does not"? We can certainly clarify in 4724bis if > that is the case. [Jim U>] If convergence is not achieved what is the > behavior. I could not determine from the draft.. > > > > > > > > I do not believe that the current GR paradigm can be extended to > cover the majority of the cases above. > > Except for the path level persistence you mentioned, I believe the GR > will be able to address all other persistence requirements you > listed, with some simple knobs and some implementation enhancements. > [Jim U>] IMO GR was originally designed to prevent churn due to > intermittent failure on an eBGP session for the IpV4 AF.. I do not > want to have different knobs and implementation enhancements to solve > the basics of persistence.. Regardless of that it does not inform the > topology of the state of a path in re the control plane it was > learned over so there can be no independent decisions about the value > of a given path by different customers/providers.. This is required > for my applications.. > > > > > > > > Thanks, > > Jim Uttaro > > Thanks. -- Enke > > > > > > > -----Original Message----- > > From: Enke Chen [mailto:enkechen@cisco.com] > > Sent: Wednesday, October 26, 2011 8:43 PM > > To: UTTARO, JAMES > > Cc: robert@raszuk.net; > idr@ietf.org List; Enke Chen > > Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 > > > > Hi, folks: > > > > I have a hard time in understanding what new problems (beyond the > GR) > > the draft try to solve :-( > > > > If the concern is about the simultaneous RR failure as shown in the > > examples in Sect. 6 Application, that can be addressed easily using > GR. > > As the RRs are not in the forwarding path, it means that the > forwarding > > is not impacted (thus is preserved) during the restart of a RR. > The > > Forwarding State bit (F) in the GR capability should always be set > by > > the RR when it is not in the forwarding path. > > > > Also in the case of simultaneous RR failure, I do not see why one > would > > want to retain some routes, but not others, using the communities > > specified in the draft. As the RRs are not in the forwarding path, > > wouldn't be better to retain all the routes on a PE/client? > > > > As you might be aware, efforts have been underway to address issues > with > > GR found during implementation and deployment. They include the spec > > respin, notification handling, and implementations. If there are > issues > > in the GR area that are not adequately addressed, I suggest that we > try > > to address them in the GR respin if possible, instead of creating > > another variation unnecessarily. > > > > Thanks. -- Enke > > > > > > On 10/26/11 10:24 AM, Robert Raszuk wrote: > > Jim, > > > > When one during design phase of a routing protocol or routing > protocol > > extension or modification to it already realizes that enabling such > > feature may cause real network issue if not done carefully - that > > should trigger the alarm to rethink the solution and explore > > alternative approaches to the problem space. > > > > We as operators have already hard time to relate enabling a feature > > within our intradomain boundaries to make sure such rollout is > network > > wide. Here you are asking for the same level of awareness across > ebgp > > boundaries. This is practically unrealistic IMHO. > > > > Back to the proposal ... I think that if anything needs to be done > is > > to employ per prefix GR with longer and locally configurable timer. > > That would address information persistence across direct IBGP > sessions. > > > > On the RRs use case of this draft we may perhaps agree to disagree, > > but I do not see large enough probability of correctly engineered RR > > plane to experience simultaneous multiple ibgp session drops. If > that > > happens the RR placement, platforms or deployment model should be > > re-engineered. > > > > Summary .. I do not think that IDR WG should adopt this document. > Just > > adding a warning to the deployment section is not sufficient. > > > > Best regards, > > R. > > > > > > Robert, > > > > The introduction of this technology needs to be carefully evaluated > > when being deployed into the network. Your example clearly calls out > > how a series of independent design can culminate in incorrect > > behavior. Certainly the deployment of persistence on a router that > > has interaction with a router that does not needs to be clearly > > understood by the network designer. The goal of this draft is to > > provide a fairly sophisticated tool that will protect the majority > of > > customers in the event of a catastrophic failure.. The premise being > > the perfect is not the enemy of the good.. I will add text in the > > deployment considerations section to better articulate that.. > > > > Thanks, Jim Uttaro > > > > -----Original Message----- From: > idr-bounces@ietf.org > > [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: > > Sunday, October 23, 2011 5:32 PM To: > idr@ietf.org List Subject: [Idr] > > draft-uttaro-idr-bgp-persistence-00 > > > > Authors, > > > > Actually when discussing this draft a new concern surfaced which I > > would like to get your answer on. > > > > The draft in section 4.2 says as one of the forwarding rules: > > > > o Forwarding to a "stale" route is only used if there are no other > > paths available to that route. In other words an active path always > > wins regardless of path selection. "Stale" state is always > > considered to be less preferred when compared with an active path. > > > > In the light of the above rule let's consider a very simple case of > > dual PE attached site of L3VPN service. Two CEs would inject into > > their IBGP mesh routes to the remote destination: one marked as > STALE > > and one not marked at all. (Each CE is connected to different PE > and > > each PE RT imports only a single route to a remote hub headquarter > to > > support geographic load balancing). > > > > Let me illustrate: > > > > VPN Customer HUB > > > > PE3 PE4 SP PE1 PE2 | | | | CE1 CE2 | > > | 1| |10 | | R1 ------ R2 1 > > > > CE1,CE2,R1,R2 are in IBGP mesh. IGP metric of CE1-R1 and R1-R2 are 1 > > and R2-CE2 is 10. > > > > Prefix X is advertised by remote hub in the given VPN such that PE1 > > vrf towards CE1 only has X via PE3 and PE2's vrf towards CE2 only > has > > X via PE4. > > > > Let's assume EBGP sessions PE3 to HUB went down, but ethernet link > > is up, next hop is in the RIB while data plane is gone. Assume no > > data plane real validation too. /* That is why in my former message > > I suggested that data plane validation would be necessary */. > > > > R1 has X via PE1/S (stale) and X via PE2/A (active) - it understands > > STALE so selects in his forwarding table path via CE2. > > > > R2 has X via PE1/S (stale) and X via PE2/A (active) - it does not > > understand STALE, never was upgraded to support the forwarding rule > > stated above in the draft and chooses X via CE1 (NH metric 2 vs 10). > > > > R1--R2 produce data plane loop as long as STALE paths are present in > > the system. Quite fun to troubleshoot too as the issue of PE3 > > injecting such STALE paths may be on the opposite site of the world. > > > > The issue occurs when some routers within the customer site will be > > able to recognize STALE transitive community and prefer non stale > > paths in their forwarding planes (or BGP planes for that matter) > > while others will not as well as when both stale and non stale paths > > will be present. > > > > Question 1: How do you prevent forwarding loop in such case ? > > > > Question 2: How do you prevent forwarding loop in the case when > > customer would have backup connectivity to his sites or connectivity > > via different VPN provider yet routers in his site only partially > > understand the STALE community and only partially follow the > > forwarding rules ? > > > > In general as the rule is about mandating some particular order of > > path forwarding selection what is the mechanism in distributed > > systems like today's routing to be able to achieve any assurance > that > > such rule is active and enforced across _all_ routers behind EBGP > > PE-CE L3VPN boundaries in customer sites ? > > > > Best regards, R. > > > > > > -------- Original Message -------- Subject: [Idr] > > draft-uttaro-idr-bgp-persistence-00 Date: Sat, 22 Oct 2011 00:23:55 > > +0200 From: Robert > Raszuk Reply-To: > > robert@raszuk.net To: > idr@ietf.org > List > > > > Hi, > > > > I have read the draft and have one question and one observation. > > > > Question: > > > > What is the point of defining DO_NOT_PERSIST community ? In other > > words why not having PERSIST community set would not mean the same > as > > having path marked with DO_NOT_PERSIST. > > > > Observation: > > > > I found the below statement in section 4.2: > > > > o Forwarding must ensure that the Next Hop to a "stale" route is > > viable. > > > > Of course I agree. But since we stating obvious in the forwarding > > section I think it would be good to explicitly also state this in > > the best path selection that next hop to STALE best path must be > > valid. > > > > However sessions especially those between loopbacks do not go down > > for no reason. Most likely there is network problem which may have > > caused those sessions to go down. It is therefor likely that LDP > > session went also down between any of the LSRs in the data path and > > that in spite of having the paths in BGP and next hops in IGP the > LSP > > required for both quoted L2/L3VPN applications is broken. That may > > particularly happen when network chooses to use independent control > > mode for label allocation. > > > > I would suggest to at least add the recommendation statement to the > > document that during best path selection especially for stale paths > > a validity of required forwarding paradigm to next hop of stale > > paths should be verified. > > > > For example using techniques as described in: > > draft-ietf-idr-bgp-bestpath-selection-criteria > > > > Best regards, R. > > > > > > _______________________________________________ Idr mailing list > > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > > > > > _______________________________________________ Idr mailing list > > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > > > > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > > > > From bruno.decraene@orange.com Mon Nov 14 23:26:43 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 111AD11E81A2 for ; Mon, 14 Nov 2011 23:26:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZLhdkCXx5Ox for ; Mon, 14 Nov 2011 23:26:42 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 44FC911E8152 for ; Mon, 14 Nov 2011 23:26:42 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 53C9D8B8003; Tue, 15 Nov 2011 08:28:04 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 491586C0003; Tue, 15 Nov 2011 08:28:04 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Nov 2011 08:26:41 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Nov 2011 08:26:38 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft minutes posted Thread-Index: AcyjX7r0PdAXgU99T9WwPwtdjgUhpwAAbyeA References: From: To: , , X-OriginalArrivalTime: 15 Nov 2011 07:26:41.0277 (UTC) FILETIME=[EB5F92D0:01CCA367] Subject: Re: [Idr] draft minutes 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, 15 Nov 2011 07:26:43 -0000 >In an effort at timeliness, draft minutes of today's meeting are = posted: "Enke: I think this is best covered in GR with a few knobs or tweaks. My suggestion since GR respin is going on to try to accommodate (some of) these requirements in GR. That would also suggest converting this from a solution document to a requirement document. Bruno: That sounds fine to me as long as the requirements are met." I'm not sure to remember what I said so this may be the correct minutes. However, for the record, with the additional context of my slide "Why = not Graceful Restart (GR)?" (slide n=B0 7) being displayed, I meant: - (from the slides & previous email on IDR) I believe GR and persistence = take different assumptions and hence have reasons to have different = routing results. In short, are different and should be. - now as you still feel otherwise, I'm fine with you trying to fulfill = the requirements extracted from the persistent draft by using GR. I'll = wait for the document and we'll have more text to discuss that point. So to sum up, currently, Enke and I are not in agreement regarding this = point. To further discuss this disagreement, it seems reasonable to me = that Enke writes a document to detail his proposition. Thanks, Bruno >-----Original Message----- >From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of = John >Scudder >Sent: Tuesday, November 15, 2011 2:28 PM >To: idr@ietf.org List >Subject: [Idr] draft minutes posted > >Folks, > >In an effort at timeliness, draft minutes of today's meeting are = posted: > >http://www.ietf.org/proceedings/82/minutes/idr.txt > >They are very, very, draft -- from my edit buffer to your ears. Feel = free to >send any comments or corrections; however you may want to wait until = the chairs >have gone one round of revision on them before spending your time on = this. >We'll update the list when they are cleaned up a little. > >Thanks, > >--John >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From jgs@juniper.net Mon Nov 14 23:52:11 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D491F0D0C for ; Mon, 14 Nov 2011 23:52:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.521 X-Spam-Level: X-Spam-Status: No, score=-6.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNyDx2klhfON for ; Mon, 14 Nov 2011 23:52:10 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id A945E1F0CF7 for ; Mon, 14 Nov 2011 23:52:09 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTsIaJ3U3E0W1tTfYEPHqQbVdMwPZDX/G@postini.com; Mon, 14 Nov 2011 23:52:10 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Mon, 14 Nov 2011 23:46:10 -0800 From: John Scudder To: "" Date: Mon, 14 Nov 2011 23:46:12 -0800 Thread-Topic: [Idr] draft minutes posted Thread-Index: AcyjaqOfw4QjAaxARqSHqrkzBAd5kw== Message-ID: <7B8DC0F8-5B7E-49C6-B04A-845C82F05F76@juniper.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" Subject: Re: [Idr] draft minutes 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, 15 Nov 2011 07:52:11 -0000 On Nov 15, 2011, at 3:26 PM, wrote: > I'm not sure to remember what I said so this may be the correct minutes. To be clear, first, these are draft minutes, second, nothing in there is a = direct quotation unless marked as such but is my attempt at a paraphrase. = So your clarification is appreciated! Thanks, --John= From bruno.decraene@orange.com Tue Nov 15 00:01:33 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0FE01F0C47 for ; Tue, 15 Nov 2011 00:01:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10pxT64X-KLQ for ; Tue, 15 Nov 2011 00:01:31 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id EE6951F0C3E for ; Tue, 15 Nov 2011 00:01:30 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 791348B8002; Tue, 15 Nov 2011 09:02:52 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 66D366C0001; Tue, 15 Nov 2011 09:02:52 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Nov 2011 09:01:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Nov 2011 09:01:24 +0100 Message-ID: In-Reply-To: <4EC21062.5020504@raszuk.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-00 Thread-Index: AcyjZdwZKlRsQyACRRy3rfjF10k/DwAAl05w References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net><4EA84254.9000400@raszuk.net> <4EA8A91C.4090305@cisco.com><4EAA496C.9070605@cisco.com> <4EC21062.5020504@raszuk.net> From: To: , X-OriginalArrivalTime: 15 Nov 2011 08:01:29.0109 (UTC) FILETIME=[C7D17450:01CCA36C] Cc: idr@ietf.org Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 08:01:33 -0000 Hi Robert, > >Hi Jim, > >You are correct that GR does not allow to propagate information by >default on what paths should be called as "suspicious". Yes, that's part of its original DNA: to locally conceal a BGP session failure which is expected to restart soon (or has already restarted) > However as >mentioned at the mic during the session we need to have a way to modify >best path selection criteria universally as opposed to continue to >invent new tools to solve point problems and punch holes in the various >implementations of BGP best path selection. Ah! If your concern is about the vehicle used to convey the information (to de-preference the route) I think we are pretty open to this. As a matter of fact, as per a previous email sent to you and IDR, I said that the use of local_pref could be envisaged within the AS. No new tools / holes punched. And on eBGP, I proposed to use the STALE community: no new attribute. If you're concerned about the community value being new, I guess we could re-use the g-shut (graceful restart) community. http://www.ietf.org/mail-archive/web/idr/current/msg05646.html >Chairs in fact responded that we will work on this when the right time >comes. > >Back to the persistence draft ... GR can address 90% of the persistence >draft requirements. Propagating information about "suspicious" paths if >at all we all agree if this is a good idea can be done today with either >setting lowest local pref, using cost community or marking with >community so your ebgp peers can interpret it correctly. > >Why do we need new way to signal this ? Cf my above point: no new way required. Point closed (again). >Also I think current -00 version has serious issues as already pointed >on the list. We need to wait till -01 is published in order to see if >those issues have been fixed. I somewhat disagree with the level of seriousness. As you did not express comments, I take that the list of point to be addressed in -01 as listed in the slides this morning are fine for you. Bruno >Best regards, >R. > > >> All, >> >> First let me apologize for not being able to attend the ietf.. >> >> After watching jabber it seems that the presentation of persistence >> degraded to something in re how we can apply multiple Band-Aids, >> patches, knobs etc... to extend GR to cover the Persistence draft.. >> IMO GR is a subset of the Persistence functionality and may be >> therefore subsumed into the Persistence draft. Philosophically GR >> makes the session the invariant and all behavior that follows is >> based upon this premise.. As stated in the slides, many of the new >> services have much looser association between the control and >> forwarding planes i.e L2VN, L3VPN, 3107 etc... >> >> Again let me clarify, when I looked at GR earlier this year it became >> clear that the basic philosophy, and rules stating when to persist, >> how long, triggers to stop would not meet the requirements I have.. >> From a philosophical point GR assumes that the paths that are >> persisting in forwarding should maintain their preference throughout >> the routing topology. Why? This seems beyond prescriptive as it does >> not provide the network operators with any flexibility as to how >> state learned over a compromised control may be viewed/used by the >> downstream routing topology including customers. From my reading of >> the draft there is no way to allow operators to persist, not-persist, >> or de pref the state (stale). Do I have this wrong? I do not think >> so.. So if we want to incorporate this ability into GR it would >> require a basic philosophical change.. of course even if this is done >> there is no way for a peer to pre-program paths it has advertised to >> be treated if there is a failure.. So, even if we perform major >> surgery there is still no way to accomplish this beyond unique >> filters and maybe CVs.. WE could call them STALE, PERSIST and >> DO_NOT_PERSIST and then build routing policy across all of our BGP >> speakers.. Then we can spends lots of time making sure that this >> bottom approach is consistent across the entire topology, and >> coordinate with customers also.. >> >> As I mentioned in a previous note ( see below ) GR does not meet >> requirements in terms of triggers that terminate GR persistence, >> timers etc... personally I am not that interested in a solution >> that fundamentally does not meet my requirements.. Most of the >> responses I have received is that GR can be extended. I do not think >> it can ever meet the requirements above and will require major >> surgery to fix the triggers, timers etc.. So the approach should be >> to fold the subset of GR functionality into the larger Persistence >> draft.. >> >> Jim Uttaro >> >> >> Enke, >> >> GR is a solution that is essentially local in scope it does not have >> the ability to inform downstream speakers of the viability of routing >> state from the point of possible control plane failure. OTOH >> Persistence does propagate the condition of state. This provides >> distinct advantages in terms of customers awareness of the SPs >> control plane. One could imagine a customer receiving a STALE path >> and responding by selecting a backup. Some of the extensions to this >> draft that I have considered in colouring of STALE to inform if the >> condition arises from a local ( PE ) or internal iBGP ( RR ) >> failures.. >> >> GR makes no distinction from STALE state and ACTIVE state.. This can >> lead to the STALE path still being preferred throughout the topology. >> IMO this is incorrect behavior regardless of the comparison. >> >> PERSISTENCE allows for a customer to indicate which paths should be >> candidates. Customers may want to immediately failover to the backup >> for some paths and not for others. GR is not capable of doing this it >> is all or nothing. The granularity is not sufficient. It needs to be >> at the path level. There may even be a case for having even more >> granularity i.e a per path timer.. GR is not capable of being >> extended for either of these cases. >> >> GR does not provide protection through successive restarts of the >> session. I believe that if this occurs the state will be invalidated. >> So for a session that is bouncing due to overload condition GR will >> not provide the required protection >> >> GR does not employ a make before break strategy. All state is >> invalidated first then the newly learned state is processed. This >> leads to routing churn especially if the majority of the state is the >> same which I am pretty sure is the case >> >> GR invalidates state due to the case of protocol error i.e A >> malformed update will invalidate all of the state. This is not the >> desired behavior. >> >> GR is not specific as to which events invoke it or not. From my read >> on the draft it is not clear if holdtime expiration invokes GR or >> not.. The draft is unclear. >> >> It is not clear to me how RRs and PEs differ in using GR. >> >> The time that state can persist is limit to about 1 hour max. >> >> GR does detail the behavior where convergence is not achieved between >> restarts.. Similar to above.. >> >> I do not believe that the current GR paradigm can be extended to >> cover the majority of the cases above. >> >> Thanks, Jim Uttaro >> >> >> From: UTTARO, JAMES Sent: Tuesday, November 01, 2011 11:20 AM To: >> 'Enke Chen' Cc: robert@raszuk.net; idr@ietf.org List Subject: RE: >> [Idr] draft-uttaro-idr-bgp-persistence-00 >> >> Enke, >> >> Comments in-Line.. >> >> Thanks, Jim Uttaro >> >> From: Enke Chen [mailto:enkechen@cisco.com] Sent: Friday, October 28, >> 2011 2:19 AM To: UTTARO, JAMES Cc: robert@raszuk.net; idr@ietf.org >> List; Enke Chen Subject: Re: [Idr] >> draft-uttaro-idr-bgp-persistence-00 >> >> Jim, >> >> My comments are inlined. >> >> On 10/27/11 1:17 PM, UTTARO, JAMES wrote: >> >> Enke, >> >> >> >> GR is a solution that is essentially local in scope it does not have >> the ability to inform downstream speakers of the viability of routing >> state from the point of possible control plane failure. OTOH >> Persistence does propagate the condition of state. This provides >> distinct advantages in terms of customers awareness of the SPs >> control plane. One could imagine a customer receiving a STALE path >> and responding by selecting a backup. Some of the extensions to this >> draft that I have considered in colouring of STALE to inform if the >> condition arises from a local ( PE ) or internal iBGP ( RR ) >> failures.. >> >> >> >> GR makes no distinction from STALE state and ACTIVE state.. This can >> lead to the STALE path still being preferred throughout the topology. >> IMO this is incorrect behavior regardless of the comparison. >> >> >> >> PERSISTENCE allows for a customer to indicate which paths should be >> candidates. Customers may want to immediately failover to the backup >> for some paths and not for others. GR is not capable of doing this it >> is all or nothing. The granularity is not sufficient. It needs to be >> at the path level. There may even be a case for having even more >> granularity i.e a per path timer.. GR is not capable of being >> extended for either of these cases. >> >> I am not sure how this path level persistence would work >> operationally. Without the detailed information of a provider's >> network, how would a customer know what kind of failures and recovery >> that they might experience? Consider the example of the >> simultaneous RR failures in the draft, why would dn't any customer >> not to want to protect against such failures? The end result could >> be that the PERSISTENCE flag is always set, thus losing its >> significance. [Jim U>] One ex would be customers who create multiple >> VPNs over different SPs.. A customer may want to take advantage of >> the knowledge that a control plane failure has occurred and migrate >> the traffic to the backup. This could be done at a path granularity >> by use of the DO_NOT_PERSIST CV. . We as SPs want to provide our >> customers with the tools needed to manage their VPNs and not >> prescribe a one size fits all solution. >> >> >> Regarding the use of the STALE state vs ACTIVE state, clearly there >> is a tradeoff. GR uses the stale routes in order to avoid >> forwarding churns, which has been a critical requirement for a long >> time. If there is a real need for favoring a ACTIVE one over a >> STALE one in GR, it can be done by a simple knob. [Jim U>] The >> current draft has no ability to inform downstream speakers of whether >> or not a path is STALE or ACTIVE. The knob may be simple but a lot of >> machinery would have to be built. This is one of the big reasons for >> the PERSIST draft. I do not understand the routing churn part in the >> context of vpnv4, vpnv2, 3107 etc... maybe the GR solution was >> constructed as a solution that primarily speaks to eBGP IPV4 >> connections for the IPV4 AF ( Internet ).. I could understand that.. >> >> >> As you know, BGP is full of knobs that adjust behaviors for different >> needs :-) [Jim U>] More Knobs.. >> >> >> >> >> >> >> >> GR does not provide protection through successive restarts of the >> session. I believe that if this occurs the state will be invalidated. >> So for a session that is bouncing due to overload condition GR will >> not provide the required protection >> >> This can be addressed by a simple knob to set the min stale timer for >> GR. [Jim U>] And yet more knobs >> >> >> >> >> >> >> >> GR does not employ a make before break strategy. All state is >> invalidated first then the newly learned state is processed. This >> leads to routing churn especially if the majority of the state is the >> same which I am pretty sure is the case >> >> Such behavior would be an implementation bug that needs to be fixed. >> But it is not an issue with the protocol itself. >> >> This is what we have in 4.2. Procedures for the Receiving Speaker, >> RFC 4724: >> >> --- >> >> The Receiving Speaker MUST replace the stale routes by the routing >> >> updates received from the peer. Once the End-of-RIB marker for an >> >> address family is received from the peer, it MUST immediately remove >> >> any routes from the peer that are still marked as stale for that >> >> address family. [Jim U>] This does not address the lack of clarity >> about make before break.. it only states that must immediately remove >> routes marked as stale. It should state that any paths that are >> learned which are the same as the STALE paths should not force the >> forwarding plane to be re-programmed for those paths.. This should be >> made clear and in general is good practice to avoid churn.. >> >> >> There are several possibilities for the premature purge of the stale >> routes. For example, the "Forwarding state" flag was somehow not set >> after the session was re-established, or the the EOR was sent >> prematurely. Further investigation will be needed in order to >> identify any possible implementation or config issues involved in >> your setup. [Jim U>] More moving parts to worry about.. >> >> >> >> >> >> >> >> GR invalidates state due to the case of protocol error i.e A >> malformed update will invalidate all of the state. This is not the >> desired behavior. >> >> It has been addressed by the following extension: >> >> http://datatracker.ietf.org/doc/draft-keyupate-idr-bgp-gr-notification/ >> >> [Jim U>] A few comments here.. I do not understand, the draft does >> not clarify that the only thing that will force a tear down is the >> cease subcode and a hard reset error code.. is the intention that >> this is the only thing that will tear it down? I guess I would like >> to see which things will and will not force a session termination in >> the original draft.. Like >> >> >> - Holdtime Expiration >> >> - Malformed Update >> >> - Consecutive Restarts.. So what does this exactly mean >> "As part of this extension, possible consecutive restarts SHOULD NOT >> delete a route (from the peer) previously marked as stale, until >> required by rules mentioned in [RFC4724]." Possible consecutive >> restarts means what? I really need clarity on this whole notion of >> when is a session truly invalidated. >> >> Why is the purpose of the following text? >> >> Once the session is re-established, both BGP speakers MUST set their >> "Forwarding State" bit to 1 if they want to apply planned graceful >> restart. The handling of the "Forwarding State" bit should be done >> as specified by the procedures of the Receiving speaker in [RFC4724] >> are applied. >> >> >> >> >> >> >> >> GR is not specific as to which events invoke it or not. From my read >> on the draft it is not clear if holdtime expiration invokes GR or >> not.. The draft is unclear. >> >> I think that it is covered by the above extension. If not, it should >> be clarified. [Jim U>] I did not see it.. >> >> >> >> >> >> It is not clear to me how RRs and PEs differ in using GR. >> >> I think that there is a main difference when a RR is not in the >> forwarding path. In that case, the RR should always set the F bit in >> the GR Capability so that its clients will continue forwarding after >> they lose the sessions with RR. It is a deployment issue, though. >> [Jim U>] Yes.. Again from an operations perspective I have to deploy >> technology differently in different parts of the network across >> multiple vendors. This is generally not a desired starting point for >> the successful deployment of new technology.. I want solutions that >> are generic and simple to deploy. >> >> >> >> >> >> >> >> The time that state can persist is limit to about 1 hour max. >> >> I think that you are talking about the "Restart time" field which has >> 12 bits and amount to about 68 minutes. The "Restart time" is for >> the session re-establishment. It does not impact the duration for >> holding stale routes after the session is re-established. [Jim U>] >> But if the session does not become re-established then the state is >> invalidated as the session terminates with an error code that GR will >> not persist through.. >> >> >> If the session does not get re-established in 68 minutes, the stale >> routes would be purged. That is a long time, isn't it? However, if >> one really wants to extend the session re-establishment time and >> continue to hold stale routes, it can be done by a simple knob. [Jim >> U>] And yet even more knobs >> >> >> >> >> >> >> >> GR does detail the behavior where convergence is not achieved between >> restarts.. Similar to above.. >> >> The min stale timer knob can cover it (see above). >> >> But do you meant "does not"? We can certainly clarify in 4724bis if >> that is the case. [Jim U>] If convergence is not achieved what is the >> behavior. I could not determine from the draft.. >> >> >> >> >> >> >> >> I do not believe that the current GR paradigm can be extended to >> cover the majority of the cases above. >> >> Except for the path level persistence you mentioned, I believe the GR >> will be able to address all other persistence requirements you >> listed, with some simple knobs and some implementation enhancements. >> [Jim U>] IMO GR was originally designed to prevent churn due to >> intermittent failure on an eBGP session for the IpV4 AF.. I do not >> want to have different knobs and implementation enhancements to solve >> the basics of persistence.. Regardless of that it does not inform the >> topology of the state of a path in re the control plane it was >> learned over so there can be no independent decisions about the value >> of a given path by different customers/providers.. This is required >> for my applications.. >> >> >> >> >> >> >> >> Thanks, >> >> Jim Uttaro >> >> Thanks. -- Enke >> >> >> >> >> >> >> -----Original Message----- >> >> From: Enke Chen [mailto:enkechen@cisco.com] >> >> Sent: Wednesday, October 26, 2011 8:43 PM >> >> To: UTTARO, JAMES >> >> Cc: robert@raszuk.net; >> idr@ietf.org List; Enke Chen >> >> Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 >> >> >> >> Hi, folks: >> >> >> >> I have a hard time in understanding what new problems (beyond the >> GR) >> >> the draft try to solve :-( >> >> >> >> If the concern is about the simultaneous RR failure as shown in the >> >> examples in Sect. 6 Application, that can be addressed easily using >> GR. >> >> As the RRs are not in the forwarding path, it means that the >> forwarding >> >> is not impacted (thus is preserved) during the restart of a RR. >> The >> >> Forwarding State bit (F) in the GR capability should always be set >> by >> >> the RR when it is not in the forwarding path. >> >> >> >> Also in the case of simultaneous RR failure, I do not see why one >> would >> >> want to retain some routes, but not others, using the communities >> >> specified in the draft. As the RRs are not in the forwarding path, >> >> wouldn't be better to retain all the routes on a PE/client? >> >> >> >> As you might be aware, efforts have been underway to address issues >> with >> >> GR found during implementation and deployment. They include the spec >> >> respin, notification handling, and implementations. If there are >> issues >> >> in the GR area that are not adequately addressed, I suggest that we >> try >> >> to address them in the GR respin if possible, instead of creating >> >> another variation unnecessarily. >> >> >> >> Thanks. -- Enke >> >> >> >> >> >> On 10/26/11 10:24 AM, Robert Raszuk wrote: >> >> Jim, >> >> >> >> When one during design phase of a routing protocol or routing >> protocol >> >> extension or modification to it already realizes that enabling such >> >> feature may cause real network issue if not done carefully - that >> >> should trigger the alarm to rethink the solution and explore >> >> alternative approaches to the problem space. >> >> >> >> We as operators have already hard time to relate enabling a feature >> >> within our intradomain boundaries to make sure such rollout is >> network >> >> wide. Here you are asking for the same level of awareness across >> ebgp >> >> boundaries. This is practically unrealistic IMHO. >> >> >> >> Back to the proposal ... I think that if anything needs to be done >> is >> >> to employ per prefix GR with longer and locally configurable timer. >> >> That would address information persistence across direct IBGP >> sessions. >> >> >> >> On the RRs use case of this draft we may perhaps agree to disagree, >> >> but I do not see large enough probability of correctly engineered RR >> >> plane to experience simultaneous multiple ibgp session drops. If >> that >> >> happens the RR placement, platforms or deployment model should be >> >> re-engineered. >> >> >> >> Summary .. I do not think that IDR WG should adopt this document. >> Just >> >> adding a warning to the deployment section is not sufficient. >> >> >> >> Best regards, >> >> R. >> >> >> >> >> >> Robert, >> >> >> >> The introduction of this technology needs to be carefully evaluated >> >> when being deployed into the network. Your example clearly calls out >> >> how a series of independent design can culminate in incorrect >> >> behavior. Certainly the deployment of persistence on a router that >> >> has interaction with a router that does not needs to be clearly >> >> understood by the network designer. The goal of this draft is to >> >> provide a fairly sophisticated tool that will protect the majority >> of >> >> customers in the event of a catastrophic failure.. The premise being >> >> the perfect is not the enemy of the good.. I will add text in the >> >> deployment considerations section to better articulate that.. >> >> >> >> Thanks, Jim Uttaro >> >> >> >> -----Original Message----- From: >> idr-bounces@ietf.org >> >> [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: >> >> Sunday, October 23, 2011 5:32 PM To: >> idr@ietf.org List Subject: [Idr] >> >> draft-uttaro-idr-bgp-persistence-00 >> >> >> >> Authors, >> >> >> >> Actually when discussing this draft a new concern surfaced which I >> >> would like to get your answer on. >> >> >> >> The draft in section 4.2 says as one of the forwarding rules: >> >> >> >> o Forwarding to a "stale" route is only used if there are no other >> >> paths available to that route. In other words an active path always >> >> wins regardless of path selection. "Stale" state is always >> >> considered to be less preferred when compared with an active path. >> >> >> >> In the light of the above rule let's consider a very simple case of >> >> dual PE attached site of L3VPN service. Two CEs would inject into >> >> their IBGP mesh routes to the remote destination: one marked as >> STALE >> >> and one not marked at all. (Each CE is connected to different PE >> and >> >> each PE RT imports only a single route to a remote hub headquarter >> to >> >> support geographic load balancing). >> >> >> >> Let me illustrate: >> >> >> >> VPN Customer HUB >> >> >> >> PE3 PE4 SP PE1 PE2 | | | | CE1 CE2 | >> >> | 1| |10 | | R1 ------ R2 1 >> >> >> >> CE1,CE2,R1,R2 are in IBGP mesh. IGP metric of CE1-R1 and R1-R2 are 1 >> >> and R2-CE2 is 10. >> >> >> >> Prefix X is advertised by remote hub in the given VPN such that PE1 >> >> vrf towards CE1 only has X via PE3 and PE2's vrf towards CE2 only >> has >> >> X via PE4. >> >> >> >> Let's assume EBGP sessions PE3 to HUB went down, but ethernet link >> >> is up, next hop is in the RIB while data plane is gone. Assume no >> >> data plane real validation too. /* That is why in my former message >> >> I suggested that data plane validation would be necessary */. >> >> >> >> R1 has X via PE1/S (stale) and X via PE2/A (active) - it understands >> >> STALE so selects in his forwarding table path via CE2. >> >> >> >> R2 has X via PE1/S (stale) and X via PE2/A (active) - it does not >> >> understand STALE, never was upgraded to support the forwarding rule >> >> stated above in the draft and chooses X via CE1 (NH metric 2 vs 10). >> >> >> >> R1--R2 produce data plane loop as long as STALE paths are present in >> >> the system. Quite fun to troubleshoot too as the issue of PE3 >> >> injecting such STALE paths may be on the opposite site of the world. >> >> >> >> The issue occurs when some routers within the customer site will be >> >> able to recognize STALE transitive community and prefer non stale >> >> paths in their forwarding planes (or BGP planes for that matter) >> >> while others will not as well as when both stale and non stale paths >> >> will be present. >> >> >> >> Question 1: How do you prevent forwarding loop in such case ? >> >> >> >> Question 2: How do you prevent forwarding loop in the case when >> >> customer would have backup connectivity to his sites or connectivity >> >> via different VPN provider yet routers in his site only partially >> >> understand the STALE community and only partially follow the >> >> forwarding rules ? >> >> >> >> In general as the rule is about mandating some particular order of >> >> path forwarding selection what is the mechanism in distributed >> >> systems like today's routing to be able to achieve any assurance >> that >> >> such rule is active and enforced across _all_ routers behind EBGP >> >> PE-CE L3VPN boundaries in customer sites ? >> >> >> >> Best regards, R. >> >> >> >> >> >> -------- Original Message -------- Subject: [Idr] >> >> draft-uttaro-idr-bgp-persistence-00 Date: Sat, 22 Oct 2011 00:23:55 >> >> +0200 From: Robert >> Raszuk Reply-To: >> >> robert@raszuk.net To: >> idr@ietf.org >> List >> >> >> >> Hi, >> >> >> >> I have read the draft and have one question and one observation. >> >> >> >> Question: >> >> >> >> What is the point of defining DO_NOT_PERSIST community ? In other >> >> words why not having PERSIST community set would not mean the same >> as >> >> having path marked with DO_NOT_PERSIST. >> >> >> >> Observation: >> >> >> >> I found the below statement in section 4.2: >> >> >> >> o Forwarding must ensure that the Next Hop to a "stale" route is >> >> viable. >> >> >> >> Of course I agree. But since we stating obvious in the forwarding >> >> section I think it would be good to explicitly also state this in >> >> the best path selection that next hop to STALE best path must be >> >> valid. >> >> >> >> However sessions especially those between loopbacks do not go down >> >> for no reason. Most likely there is network problem which may have >> >> caused those sessions to go down. It is therefor likely that LDP >> >> session went also down between any of the LSRs in the data path and >> >> that in spite of having the paths in BGP and next hops in IGP the >> LSP >> >> required for both quoted L2/L3VPN applications is broken. That may >> >> particularly happen when network chooses to use independent control >> >> mode for label allocation. >> >> >> >> I would suggest to at least add the recommendation statement to the >> >> document that during best path selection especially for stale paths >> >> a validity of required forwarding paradigm to next hop of stale >> >> paths should be verified. >> >> >> >> For example using techniques as described in: >> >> draft-ietf-idr-bgp-bestpath-selection-criteria >> >> >> >> Best regards, R. >> >> >> >> >> >> _______________________________________________ Idr mailing list >> >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> >> >> >> >> >> _______________________________________________ Idr mailing list >> >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> >> >> >> >> >> >> >> _______________________________________________ >> >> Idr mailing list >> >> Idr@ietf.org >> >> https://www.ietf.org/mailman/listinfo/idr >> >> >> >> > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From bruno.decraene@orange.com Tue Nov 15 00:06:11 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB6211E8085 for ; Tue, 15 Nov 2011 00:06:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.182 X-Spam-Level: X-Spam-Status: No, score=-2.182 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YXytKNeq18s for ; Tue, 15 Nov 2011 00:06:10 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1EA11E8081 for ; Tue, 15 Nov 2011 00:06:10 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E273D8B8002; Tue, 15 Nov 2011 09:07:32 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id D7D426C0001; Tue, 15 Nov 2011 09:07:32 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Nov 2011 09:06:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Nov 2011 09:06:07 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-00 Thread-Index: AcyjZdwZKlRsQyACRRy3rfjF10k/DwAAl05wAAE+F9A= References: <4EA1F0FB.3090100@raszuk.net><4EA487E4.2040201@raszuk.net><4EA84254.9000400@raszuk.net><4EA8A91C.4090305@cisco.com><4EAA496C.9070605@cisco.com><4EC21062.5020504@raszuk.net> From: To: , , X-OriginalArrivalTime: 15 Nov 2011 08:06:09.0948 (UTC) FILETIME=[6F3615C0:01CCA36D] Cc: idr@ietf.org Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 08:06:11 -0000 > If you're concerned about the community value being new, >I guess we could re-use the g-shut (graceful restart) community. I meant graceful shutdown. Sorry. From ju1738@att.com Tue Nov 15 06:11:23 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F7421F8BA4 for ; Tue, 15 Nov 2011 06:11:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.554 X-Spam-Level: X-Spam-Status: No, score=-105.554 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gk--QRvD94fK for ; Tue, 15 Nov 2011 06:11:19 -0800 (PST) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 6A16221F8CA4 for ; Tue, 15 Nov 2011 06:11:19 -0800 (PST) X-Env-Sender: ju1738@att.com X-Msg-Ref: server-10.tower-120.messagelabs.com!1321366276!36301985!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13523 invoked from network); 15 Nov 2011 14:11:17 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-10.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Nov 2011 14:11:17 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pAFEBi2H013559; Tue, 15 Nov 2011 09:11:44 -0500 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pAFEBdbf013459 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Nov 2011 09:11:39 -0500 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([169.254.1.53]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.01.0339.001; Tue, 15 Nov 2011 09:11:10 -0500 From: "UTTARO, JAMES" To: "'robert@raszuk.net'" Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-00 Thread-Index: AQHMkEAnLP0iAkRlVkChUYWtkZqOMZWKuQoAgAQhplCAAIdcwoABIPrwgAESmgCABpCw8IAVN//QgACgTgCAAB3Q8A== Date: Tue, 15 Nov 2011 14:11:10 +0000 Message-ID: References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net> <4EA84254.9000400@raszuk.net> <4EA8A91C.4090305@cisco.com> <4EAA496C.9070605@cisco.com> <4EC21062.5020504@raszuk.net> In-Reply-To: <4EC21062.5020504@raszuk.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.21.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'idr@ietf.org List'" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 14:11:23 -0000 Robert, Comments In-Line.. Jim Uttaro -----Original Message----- From: Robert Raszuk [mailto:robert@raszuk.net]=20 Sent: Tuesday, November 15, 2011 2:10 AM To: UTTARO, JAMES Cc: 'Enke Chen'; 'idr@ietf.org List' Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 Hi Jim, You are correct that GR does not allow to propagate information by=20 default on what paths should be called as "suspicious". However as=20 mentioned at the mic during the session we need to have a way to modify=20 best path selection criteria universally as opposed to continue to=20 invent new tools to solve point problems and punch holes in the various=20 implementations of BGP best path selected [Jim U>] So two distinct items here.. 1) GR cannot propagate information in= re paths. From the draft there seems to be no way to do this for all paths= or some subset of paths without major surgery. So, do you agree with this = statement? 2) Punching holes?? So here are a few examples where holes have= been punched RT-Constrain, AIGP, L2VPN, etc... So, are all of these going = to be addressed? Will all further drafts that "tweak" best path selection b= e parked until this done.. The tools serve a real business/service/network = need so cannot afford to wait.. Chairs in fact responded that we will work on this when the right time=20 comes. [Jim U>] That is fine.. In the meantime work will continue.. Back to the persistence draft ... GR can address 90% of the persistence=20 draft requirements. [Jim U>] Disagree.. See my prior note.. Propagating information about "suspicious" paths if=20 at all we all agree if this is a good idea can be done today with either=20 setting lowest local pref, using cost community or marking with=20 community so your ebgp peers can interpret it correctly. [Jim U>] Need to be careful when we use customer tools i.e LP to accomplish= provider goals. This type of approach may conflict with RFC1998.. Marking = paths with CVs does not influence best path decision unless policy is appli= ed at every point. This is not a workable solution in a large network Why do we need new way to signal this ? [Jim U>] ? See Above. Also I think current -00 version has serious issues as already pointed=20 on the list. We need to wait till -01 is published in order to see if=20 those issues have been fixed. [Jim U>] Disagree.. I do believe that the draft needs to evolve in how it d= eals with different use cases and the peculiarities of each.. IMO the purpo= se of IETF specifications is to provide tools for designers. We cannot take= an approach that we will not develop tools as designers may not understand= how to use them and could screw up their networks.. if this is the approac= h then we probably need to retire lots of technology that can be used incor= rectly.. The argument that designers can screw up their network is specious= at best.. Best regards, R. > All, > > First let me apologize for not being able to attend the ietf.. > > After watching jabber it seems that the presentation of persistence > degraded to something in re how we can apply multiple Band-Aids, > patches, knobs etc... to extend GR to cover the Persistence draft.. > IMO GR is a subset of the Persistence functionality and may be > therefore subsumed into the Persistence draft. Philosophically GR > makes the session the invariant and all behavior that follows is > based upon this premise.. As stated in the slides, many of the new > services have much looser association between the control and > forwarding planes i.e L2VN, L3VPN, 3107 etc... > > Again let me clarify, when I looked at GR earlier this year it became > clear that the basic philosophy, and rules stating when to persist, > how long, triggers to stop would not meet the requirements I have.. > From a philosophical point GR assumes that the paths that are > persisting in forwarding should maintain their preference throughout > the routing topology. Why? This seems beyond prescriptive as it does > not provide the network operators with any flexibility as to how > state learned over a compromised control may be viewed/used by the > downstream routing topology including customers. From my reading of > the draft there is no way to allow operators to persist, not-persist, > or de pref the state (stale). Do I have this wrong? I do not think > so.. So if we want to incorporate this ability into GR it would > require a basic philosophical change.. of course even if this is done > there is no way for a peer to pre-program paths it has advertised to > be treated if there is a failure.. So, even if we perform major > surgery there is still no way to accomplish this beyond unique > filters and maybe CVs.. WE could call them STALE, PERSIST and > DO_NOT_PERSIST and then build routing policy across all of our BGP > speakers.. Then we can spends lots of time making sure that this > bottom approach is consistent across the entire topology, and > coordinate with customers also.. > > As I mentioned in a previous note ( see below ) GR does not meet > requirements in terms of triggers that terminate GR persistence, > timers etc... personally I am not that interested in a solution > that fundamentally does not meet my requirements.. Most of the > responses I have received is that GR can be extended. I do not think > it can ever meet the requirements above and will require major > surgery to fix the triggers, timers etc.. So the approach should be > to fold the subset of GR functionality into the larger Persistence > draft.. > > Jim Uttaro > > > Enke, > > GR is a solution that is essentially local in scope it does not have > the ability to inform downstream speakers of the viability of routing > state from the point of possible control plane failure. OTOH > Persistence does propagate the condition of state. This provides > distinct advantages in terms of customers awareness of the SPs > control plane. One could imagine a customer receiving a STALE path > and responding by selecting a backup. Some of the extensions to this > draft that I have considered in colouring of STALE to inform if the > condition arises from a local ( PE ) or internal iBGP ( RR ) > failures.. > > GR makes no distinction from STALE state and ACTIVE state.. This can > lead to the STALE path still being preferred throughout the topology. > IMO this is incorrect behavior regardless of the comparison. > > PERSISTENCE allows for a customer to indicate which paths should be > candidates. Customers may want to immediately failover to the backup > for some paths and not for others. GR is not capable of doing this it > is all or nothing. The granularity is not sufficient. It needs to be > at the path level. There may even be a case for having even more > granularity i.e a per path timer.. GR is not capable of being > extended for either of these cases. > > GR does not provide protection through successive restarts of the > session. I believe that if this occurs the state will be invalidated. > So for a session that is bouncing due to overload condition GR will > not provide the required protection > > GR does not employ a make before break strategy. All state is > invalidated first then the newly learned state is processed. This > leads to routing churn especially if the majority of the state is the > same which I am pretty sure is the case > > GR invalidates state due to the case of protocol error i.e A > malformed update will invalidate all of the state. This is not the > desired behavior. > > GR is not specific as to which events invoke it or not. From my read > on the draft it is not clear if holdtime expiration invokes GR or > not.. The draft is unclear. > > It is not clear to me how RRs and PEs differ in using GR. > > The time that state can persist is limit to about 1 hour max. > > GR does detail the behavior where convergence is not achieved between > restarts.. Similar to above.. > > I do not believe that the current GR paradigm can be extended to > cover the majority of the cases above. > > Thanks, Jim Uttaro > > > From: UTTARO, JAMES Sent: Tuesday, November 01, 2011 11:20 AM To: > 'Enke Chen' Cc: robert@raszuk.net; idr@ietf.org List Subject: RE: > [Idr] draft-uttaro-idr-bgp-persistence-00 > > Enke, > > Comments in-Line.. > > Thanks, Jim Uttaro > > From: Enke Chen [mailto:enkechen@cisco.com] Sent: Friday, October 28, > 2011 2:19 AM To: UTTARO, JAMES Cc: robert@raszuk.net; idr@ietf.org > List; Enke Chen Subject: Re: [Idr] > draft-uttaro-idr-bgp-persistence-00 > > Jim, > > My comments are inlined. > > On 10/27/11 1:17 PM, UTTARO, JAMES wrote: > > Enke, > > > > GR is a solution that is essentially local in scope it does not have > the ability to inform downstream speakers of the viability of routing > state from the point of possible control plane failure. OTOH > Persistence does propagate the condition of state. This provides > distinct advantages in terms of customers awareness of the SPs > control plane. One could imagine a customer receiving a STALE path > and responding by selecting a backup. Some of the extensions to this > draft that I have considered in colouring of STALE to inform if the > condition arises from a local ( PE ) or internal iBGP ( RR ) > failures.. > > > > GR makes no distinction from STALE state and ACTIVE state.. This can > lead to the STALE path still being preferred throughout the topology. > IMO this is incorrect behavior regardless of the comparison. > > > > PERSISTENCE allows for a customer to indicate which paths should be > candidates. Customers may want to immediately failover to the backup > for some paths and not for others. GR is not capable of doing this it > is all or nothing. The granularity is not sufficient. It needs to be > at the path level. There may even be a case for having even more > granularity i.e a per path timer.. GR is not capable of being > extended for either of these cases. > > I am not sure how this path level persistence would work > operationally. Without the detailed information of a provider's > network, how would a customer know what kind of failures and recovery > that they might experience? Consider the example of the > simultaneous RR failures in the draft, why would dn't any customer > not to want to protect against such failures? The end result could > be that the PERSISTENCE flag is always set, thus losing its > significance. [Jim U>] One ex would be customers who create multiple > VPNs over different SPs.. A customer may want to take advantage of > the knowledge that a control plane failure has occurred and migrate > the traffic to the backup. This could be done at a path granularity > by use of the DO_NOT_PERSIST CV. . We as SPs want to provide our > customers with the tools needed to manage their VPNs and not > prescribe a one size fits all solution. > > > Regarding the use of the STALE state vs ACTIVE state, clearly there > is a tradeoff. GR uses the stale routes in order to avoid > forwarding churns, which has been a critical requirement for a long > time. If there is a real need for favoring a ACTIVE one over a > STALE one in GR, it can be done by a simple knob. [Jim U>] The > current draft has no ability to inform downstream speakers of whether > or not a path is STALE or ACTIVE. The knob may be simple but a lot of > machinery would have to be built. This is one of the big reasons for > the PERSIST draft. I do not understand the routing churn part in the > context of vpnv4, vpnv2, 3107 etc... maybe the GR solution was > constructed as a solution that primarily speaks to eBGP IPV4 > connections for the IPV4 AF ( Internet ).. I could understand that.. > > > As you know, BGP is full of knobs that adjust behaviors for different > needs :-) [Jim U>] More Knobs.. > > > > > > > > GR does not provide protection through successive restarts of the > session. I believe that if this occurs the state will be invalidated. > So for a session that is bouncing due to overload condition GR will > not provide the required protection > > This can be addressed by a simple knob to set the min stale timer for > GR. [Jim U>] And yet more knobs > > > > > > > > GR does not employ a make before break strategy. All state is > invalidated first then the newly learned state is processed. This > leads to routing churn especially if the majority of the state is the > same which I am pretty sure is the case > > Such behavior would be an implementation bug that needs to be fixed. > But it is not an issue with the protocol itself. > > This is what we have in 4.2. Procedures for the Receiving Speaker, > RFC 4724: > > --- > > The Receiving Speaker MUST replace the stale routes by the routing > > updates received from the peer. Once the End-of-RIB marker for an > > address family is received from the peer, it MUST immediately remove > > any routes from the peer that are still marked as stale for that > > address family. [Jim U>] This does not address the lack of clarity > about make before break.. it only states that must immediately remove > routes marked as stale. It should state that any paths that are > learned which are the same as the STALE paths should not force the > forwarding plane to be re-programmed for those paths.. This should be > made clear and in general is good practice to avoid churn.. > > > There are several possibilities for the premature purge of the stale > routes. For example, the "Forwarding state" flag was somehow not set > after the session was re-established, or the the EOR was sent > prematurely. Further investigation will be needed in order to > identify any possible implementation or config issues involved in > your setup. [Jim U>] More moving parts to worry about.. > > > > > > > > GR invalidates state due to the case of protocol error i.e A > malformed update will invalidate all of the state. This is not the > desired behavior. > > It has been addressed by the following extension: > > http://datatracker.ietf.org/doc/draft-keyupate-idr-bgp-gr-notification/ > > [Jim U>] A few comments here.. I do not understand, the draft does > not clarify that the only thing that will force a tear down is the > cease subcode and a hard reset error code.. is the intention that > this is the only thing that will tear it down? I guess I would like > to see which things will and will not force a session termination in > the original draft.. Like > > > - Holdtime Expiration > > - Malformed Update > > - Consecutive Restarts.. So what does this exactly mean > "As part of this extension, possible consecutive restarts SHOULD NOT > delete a route (from the peer) previously marked as stale, until > required by rules mentioned in [RFC4724]." Possible consecutive > restarts means what? I really need clarity on this whole notion of > when is a session truly invalidated. > > Why is the purpose of the following text? > > Once the session is re-established, both BGP speakers MUST set their > "Forwarding State" bit to 1 if they want to apply planned graceful > restart. The handling of the "Forwarding State" bit should be done > as specified by the procedures of the Receiving speaker in [RFC4724] > are applied. > > > > > > > > GR is not specific as to which events invoke it or not. From my read > on the draft it is not clear if holdtime expiration invokes GR or > not.. The draft is unclear. > > I think that it is covered by the above extension. If not, it should > be clarified. [Jim U>] I did not see it.. > > > > > > It is not clear to me how RRs and PEs differ in using GR. > > I think that there is a main difference when a RR is not in the > forwarding path. In that case, the RR should always set the F bit in > the GR Capability so that its clients will continue forwarding after > they lose the sessions with RR. It is a deployment issue, though. > [Jim U>] Yes.. Again from an operations perspective I have to deploy > technology differently in different parts of the network across > multiple vendors. This is generally not a desired starting point for > the successful deployment of new technology.. I want solutions that > are generic and simple to deploy. > > > > > > > > The time that state can persist is limit to about 1 hour max. > > I think that you are talking about the "Restart time" field which has > 12 bits and amount to about 68 minutes. The "Restart time" is for > the session re-establishment. It does not impact the duration for > holding stale routes after the session is re-established. [Jim U>] > But if the session does not become re-established then the state is > invalidated as the session terminates with an error code that GR will > not persist through.. > > > If the session does not get re-established in 68 minutes, the stale > routes would be purged. That is a long time, isn't it? However, if > one really wants to extend the session re-establishment time and > continue to hold stale routes, it can be done by a simple knob. [Jim > U>] And yet even more knobs > > > > > > > > GR does detail the behavior where convergence is not achieved between > restarts.. Similar to above.. > > The min stale timer knob can cover it (see above). > > But do you meant "does not"? We can certainly clarify in 4724bis if > that is the case. [Jim U>] If convergence is not achieved what is the > behavior. I could not determine from the draft.. > > > > > > > > I do not believe that the current GR paradigm can be extended to > cover the majority of the cases above. > > Except for the path level persistence you mentioned, I believe the GR > will be able to address all other persistence requirements you > listed, with some simple knobs and some implementation enhancements. > [Jim U>] IMO GR was originally designed to prevent churn due to > intermittent failure on an eBGP session for the IpV4 AF.. I do not > want to have different knobs and implementation enhancements to solve > the basics of persistence.. Regardless of that it does not inform the > topology of the state of a path in re the control plane it was > learned over so there can be no independent decisions about the value > of a given path by different customers/providers.. This is required > for my applications.. > > > > > > > > Thanks, > > Jim Uttaro > > Thanks. -- Enke > > > > > > > -----Original Message----- > > From: Enke Chen [mailto:enkechen@cisco.com] > > Sent: Wednesday, October 26, 2011 8:43 PM > > To: UTTARO, JAMES > > Cc: robert@raszuk.net; > idr@ietf.org List; Enke Chen > > Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 > > > > Hi, folks: > > > > I have a hard time in understanding what new problems (beyond the > GR) > > the draft try to solve :-( > > > > If the concern is about the simultaneous RR failure as shown in the > > examples in Sect. 6 Application, that can be addressed easily using > GR. > > As the RRs are not in the forwarding path, it means that the > forwarding > > is not impacted (thus is preserved) during the restart of a RR. > The > > Forwarding State bit (F) in the GR capability should always be set > by > > the RR when it is not in the forwarding path. > > > > Also in the case of simultaneous RR failure, I do not see why one > would > > want to retain some routes, but not others, using the communities > > specified in the draft. As the RRs are not in the forwarding path, > > wouldn't be better to retain all the routes on a PE/client? > > > > As you might be aware, efforts have been underway to address issues > with > > GR found during implementation and deployment. They include the spec > > respin, notification handling, and implementations. If there are > issues > > in the GR area that are not adequately addressed, I suggest that we > try > > to address them in the GR respin if possible, instead of creating > > another variation unnecessarily. > > > > Thanks. -- Enke > > > > > > On 10/26/11 10:24 AM, Robert Raszuk wrote: > > Jim, > > > > When one during design phase of a routing protocol or routing > protocol > > extension or modification to it already realizes that enabling such > > feature may cause real network issue if not done carefully - that > > should trigger the alarm to rethink the solution and explore > > alternative approaches to the problem space. > > > > We as operators have already hard time to relate enabling a feature > > within our intradomain boundaries to make sure such rollout is > network > > wide. Here you are asking for the same level of awareness across > ebgp > > boundaries. This is practically unrealistic IMHO. > > > > Back to the proposal ... I think that if anything needs to be done > is > > to employ per prefix GR with longer and locally configurable timer. > > That would address information persistence across direct IBGP > sessions. > > > > On the RRs use case of this draft we may perhaps agree to disagree, > > but I do not see large enough probability of correctly engineered RR > > plane to experience simultaneous multiple ibgp session drops. If > that > > happens the RR placement, platforms or deployment model should be > > re-engineered. > > > > Summary .. I do not think that IDR WG should adopt this document. > Just > > adding a warning to the deployment section is not sufficient. > > > > Best regards, > > R. > > > > > > Robert, > > > > The introduction of this technology needs to be carefully evaluated > > when being deployed into the network. Your example clearly calls out > > how a series of independent design can culminate in incorrect > > behavior. Certainly the deployment of persistence on a router that > > has interaction with a router that does not needs to be clearly > > understood by the network designer. The goal of this draft is to > > provide a fairly sophisticated tool that will protect the majority > of > > customers in the event of a catastrophic failure.. The premise being > > the perfect is not the enemy of the good.. I will add text in the > > deployment considerations section to better articulate that.. > > > > Thanks, Jim Uttaro > > > > -----Original Message----- From: > idr-bounces@ietf.org > > [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: > > Sunday, October 23, 2011 5:32 PM To: > idr@ietf.org List Subject: [Idr] > > draft-uttaro-idr-bgp-persistence-00 > > > > Authors, > > > > Actually when discussing this draft a new concern surfaced which I > > would like to get your answer on. > > > > The draft in section 4.2 says as one of the forwarding rules: > > > > o Forwarding to a "stale" route is only used if there are no other > > paths available to that route. In other words an active path always > > wins regardless of path selection. "Stale" state is always > > considered to be less preferred when compared with an active path. > > > > In the light of the above rule let's consider a very simple case of > > dual PE attached site of L3VPN service. Two CEs would inject into > > their IBGP mesh routes to the remote destination: one marked as > STALE > > and one not marked at all. (Each CE is connected to different PE > and > > each PE RT imports only a single route to a remote hub headquarter > to > > support geographic load balancing). > > > > Let me illustrate: > > > > VPN Customer HUB > > > > PE3 PE4 SP PE1 PE2 | | | | CE1 CE2 | > > | 1| |10 | | R1 ------ R2 1 > > > > CE1,CE2,R1,R2 are in IBGP mesh. IGP metric of CE1-R1 and R1-R2 are 1 > > and R2-CE2 is 10. > > > > Prefix X is advertised by remote hub in the given VPN such that PE1 > > vrf towards CE1 only has X via PE3 and PE2's vrf towards CE2 only > has > > X via PE4. > > > > Let's assume EBGP sessions PE3 to HUB went down, but ethernet link > > is up, next hop is in the RIB while data plane is gone. Assume no > > data plane real validation too. /* That is why in my former message > > I suggested that data plane validation would be necessary */. > > > > R1 has X via PE1/S (stale) and X via PE2/A (active) - it understands > > STALE so selects in his forwarding table path via CE2. > > > > R2 has X via PE1/S (stale) and X via PE2/A (active) - it does not > > understand STALE, never was upgraded to support the forwarding rule > > stated above in the draft and chooses X via CE1 (NH metric 2 vs 10). > > > > R1--R2 produce data plane loop as long as STALE paths are present in > > the system. Quite fun to troubleshoot too as the issue of PE3 > > injecting such STALE paths may be on the opposite site of the world. > > > > The issue occurs when some routers within the customer site will be > > able to recognize STALE transitive community and prefer non stale > > paths in their forwarding planes (or BGP planes for that matter) > > while others will not as well as when both stale and non stale paths > > will be present. > > > > Question 1: How do you prevent forwarding loop in such case ? > > > > Question 2: How do you prevent forwarding loop in the case when > > customer would have backup connectivity to his sites or connectivity > > via different VPN provider yet routers in his site only partially > > understand the STALE community and only partially follow the > > forwarding rules ? > > > > In general as the rule is about mandating some particular order of > > path forwarding selection what is the mechanism in distributed > > systems like today's routing to be able to achieve any assurance > that > > such rule is active and enforced across _all_ routers behind EBGP > > PE-CE L3VPN boundaries in customer sites ? > > > > Best regards, R. > > > > > > -------- Original Message -------- Subject: [Idr] > > draft-uttaro-idr-bgp-persistence-00 Date: Sat, 22 Oct 2011 00:23:55 > > +0200 From: Robert > Raszuk Reply-To: > > robert@raszuk.net To: > idr@ietf.org > List > > > > Hi, > > > > I have read the draft and have one question and one observation. > > > > Question: > > > > What is the point of defining DO_NOT_PERSIST community ? In other > > words why not having PERSIST community set would not mean the same > as > > having path marked with DO_NOT_PERSIST. > > > > Observation: > > > > I found the below statement in section 4.2: > > > > o Forwarding must ensure that the Next Hop to a "stale" route is > > viable. > > > > Of course I agree. But since we stating obvious in the forwarding > > section I think it would be good to explicitly also state this in > > the best path selection that next hop to STALE best path must be > > valid. > > > > However sessions especially those between loopbacks do not go down > > for no reason. Most likely there is network problem which may have > > caused those sessions to go down. It is therefor likely that LDP > > session went also down between any of the LSRs in the data path and > > that in spite of having the paths in BGP and next hops in IGP the > LSP > > required for both quoted L2/L3VPN applications is broken. That may > > particularly happen when network chooses to use independent control > > mode for label allocation. > > > > I would suggest to at least add the recommendation statement to the > > document that during best path selection especially for stale paths > > a validity of required forwarding paradigm to next hop of stale > > paths should be verified. > > > > For example using techniques as described in: > > draft-ietf-idr-bgp-bestpath-selection-criteria > > > > Best regards, R. > > > > > > _______________________________________________ Idr mailing list > > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > > > > > _______________________________________________ Idr mailing list > > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > > > > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > > > > From robert@raszuk.net Tue Nov 15 07:54:48 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1BC21F8B49 for ; Tue, 15 Nov 2011 07:54:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMdkY5mpkjdE for ; Tue, 15 Nov 2011 07:54:47 -0800 (PST) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2A621F8AF5 for ; Tue, 15 Nov 2011 07:54:47 -0800 (PST) Received: (qmail 14082 invoked by uid 399); 15 Nov 2011 15:54:46 -0000 Received: from unknown (HELO ?10.0.1.3?) (130.129.67.115) by mail1310.opentransfer.com with ESMTP; 15 Nov 2011 15:54:46 -0000 X-Originating-IP: 130.129.67.115 Message-ID: <4EC28B45.1040509@raszuk.net> Date: Tue, 15 Nov 2011 16:54:45 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "UTTARO, JAMES" References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net> <4EA84254.9000400@raszuk.net> <4EA8A91C.4090305@cisco.com> <4EAA496C.9070605@cisco.com> <4EC21062.5020504@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'idr@ietf.org List'" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 15:54:48 -0000 Jim, [Jim U>] So > two distinct items here.. 1) GR cannot propagate information in re > paths. From the draft there seems to be no way to do this for all > paths or some subset of paths without major surgery. So, do you agree > with this statement? Yes I do. First we need to agree if such introduction of propagation of information is a feature or a bug. I am personally completely not convinced that there is any value in informing my peers that one of my BGP sessions went down. You either have reachability to next hop and can attract traffic or you do not and if so you withdraw. Telling peers that "I may be perhaps used to reach prefix X as last resort" is of highly questionable value. Then as it has been said GR could be instrumented to upon session down event in case some/all best paths were on this session they could be re advertised with low local pref or with cost community. This is your own personal decision and I do not have anything against you configuring your network this way - if anything blackholed customers will seek new SP - so I am supportive my competitors to enable such knob. 2) Punching holes?? So here are a few examples > where holes have been punched RT-Constrain, AIGP, L2VPN, etc... I think you are mixing things ... RT-Constrain is a new SAFI and you can define for each new SAFI rules how best path is computed. Same for L2VPNs - the key is that you define it along the new SAFI definition. AIGP as far as I know is in the IDR holding pattern till we figure out how to consistently modify best path selection with external influences. If it comes after you are much better to use standard best path modification which guarantees best path correctness across your network. > Back to the persistence draft ... GR can address 90% of the > persistence draft requirements. [Jim U>] Disagree.. See my prior > note.. So what else is missing ? Propagation part that path is "suspicious" and all routers in the given AFI/SAFI reachability in the Internet should sort of dislike it ? Is that it ? I think it would be great for all to understand the delta. So if this is the delta I think in fact that Bruno who presented the draft is very flexible in this space. Other co-authors I spoke with were not even aware some communities were added to the draft like STALE ..... [Jim U>] > Need to be careful when we use customer tools i.e LP to accomplish > provider goals. This type of approach may conflict with RFC1998.. Local pref is AS tool - not customer tool. It is not propagated across AS boundaries. Besides your STALE community already is said to overwrite any other preference so I see completely no substantial point of your above comment. > Marking paths with CVs does not influence best path decision unless > policy is applied at every point. This is not a workable solution in > a large network Local pref is applied at every router as far as I know. STALE will also not be magically enabled everywhere in the network till the network is upgraded and knob is configured. Is this workable in large network ??? > Also I think current -00 version has serious issues as already > pointed on the list. We need to wait till -01 is published in order > to see if those issues have been fixed. [Jim U>] Disagree.. I do > believe that the draft needs to evolve in how it deals with different > use cases and the peculiarities of each.. IMO the purpose of IETF > specifications is to provide tools for designers. We cannot take an > approach that we will not develop tools as designers may not > understand how to use them and could screw up their networks.. if > this is the approach then we probably need to retire lots of > technology that can be used incorrectly.. The argument that designers > can screw up their network is specious at best.. I think this proves you are missing the loop case I described in the other email. It is fine to provide rope and count that you use it wisely for climbing the cliff. However it is IMHO wrong thing to provide a tool which has no way of working correctly ... in this particular case STALE CV across EBGP session - simply as you as operator are not aware about your peers topology and support of routing platform in their ASes. Bruno offered to change this to G-SHUT which in turn is designed to be mapped to local-pref. I have no problem with this approach. So you can achieve exactly what you need safely. To summarize .. I do recommend the same as Enke said at the mic .. It would be much better to turn this current document into requirements document so WG could provide opinions and proposals on how to solve them (provided they are valid) rather then propose a solution and keep arguing that this is the best one to solve your yet to be well defined problem. Best, R. From ju1738@att.com Tue Nov 15 08:48:31 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C190921F8B17 for ; Tue, 15 Nov 2011 08:48:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.14 X-Spam-Level: X-Spam-Status: No, score=-106.14 tagged_above=-999 required=5 tests=[AWL=0.459, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUm8wCWg5Evc for ; Tue, 15 Nov 2011 08:48:30 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 8C38E21F8B16 for ; Tue, 15 Nov 2011 08:48:30 -0800 (PST) X-Env-Sender: ju1738@att.com X-Msg-Ref: server-8.tower-119.messagelabs.com!1321375708!1184334!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27035 invoked from network); 15 Nov 2011 16:48:28 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-8.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Nov 2011 16:48:28 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pAFGmtgR020275; Tue, 15 Nov 2011 11:48:56 -0500 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pAFGmqBg020206 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Nov 2011 11:48:52 -0500 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([169.254.1.53]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.01.0339.001; Tue, 15 Nov 2011 11:48:24 -0500 From: "UTTARO, JAMES" To: "'robert@raszuk.net'" Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-00 Thread-Index: AQHMkEAnLP0iAkRlVkChUYWtkZqOMZWKuQoAgAQhplCAAIdcwoABIPrwgAESmgCABpCw8IAVN//QgACgTgCAAB3Q8IAAdK6A//+wnNA= Date: Tue, 15 Nov 2011 16:48:23 +0000 Message-ID: References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net> <4EA84254.9000400@raszuk.net> <4EA8A91C.4090305@cisco.com> <4EAA496C.9070605@cisco.com> <4EC21062.5020504@raszuk.net> <4EC28B45.1040509@raszuk.net> In-Reply-To: <4EC28B45.1040509@raszuk.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.21.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'idr@ietf.org List'" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 16:48:31 -0000 Robert=20 Comments In-line.. Jim Uttaro -----Original Message----- From: Robert Raszuk [mailto:robert@raszuk.net]=20 Sent: Tuesday, November 15, 2011 10:55 AM To: UTTARO, JAMES Cc: 'Enke Chen'; 'idr@ietf.org List' Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 Jim, [Jim U>] So > two distinct items here.. 1) GR cannot propagate information in re > paths. From the draft there seems to be no way to do this for all > paths or some subset of paths without major surgery. So, do you agree > with this statement? Yes I do. First we need to agree if such introduction of propagation of=20 information is a feature or a bug. [Jim U>] Ok.. Then you should revisit GR not propagating the failure and de= termine if it is a bug or a feature.. I am personally completely not convinced that there is any value in=20 informing my peers that one of my BGP sessions went down. You either=20 have reachability to next hop and can attract traffic or you do not and=20 if so you withdraw. [Jim U>] Ok so GR is still propagating some path from a BGP session that we= nt down or is compromised.. So what is the point here? Ok for GR but not ok= for Persistence?? Telling peers that "I may be perhaps used to reach prefix X as last=20 resort" is of highly questionable value. [Jim U>] As opposed to not telling peers that X, that may be of questionabl= e value is still the best path? Just because you are not literally informin= g your peers does not mean that you are still essentially maintaining an X = of questionable value throughout the routing context. The difference betwee= n the two is GR hides this information Persistence does not. GR is opaque, = Persistence is transparent.. It seems arrogant to hide the information from= your customers especially when it is their VPN routing context.. Then as it has been said GR could be instrumented to upon session down=20 event in case some/all best paths were on this session they could be re=20 advertised with low local pref or with cost community. This is your own=20 personal decision and I do not have anything against you configuring=20 your network this way - if anything blackholed customers will seek new=20 SP - so I am supportive my competitors to enable such knob. 2) Punching holes?? So here are a few examples > where holes have been punched RT-Constrain, AIGP, L2VPN, etc... I think you are mixing things ... RT-Constrain is a new SAFI and you can=20 define for each new SAFI rules how best path is computed. [Jim U>] The point is that RT-Constrain modifies the best path selection by= essentially punching holes.. So I guess your point is it is ok for this AF= I/SAFI but not other.. From the RT-Constrain draft: " ii. When advertising a RT membership NLRI to a non client peer, if the best path as selected by path selection procedure described in section 9.1 of the base BGP specification [5] is a route received from a non-client peer, and there is an alternative path to the same destination from a client, the attributes of the client path are advertised to the peer. " This seems like a punched hole.. NO?=20 Same for=20 L2VPNs - the key is that you define it along the new SAFI definition. AIGP as far as I know is in the IDR holding pattern till we figure out=20 how to consistently modify best path selection with external influences. [Jim U>] Really.. If it comes after you are much better to use standard best path=20 modification which guarantees best path correctness across your network. [Jim U>] so, I guess your point is if Best Path changes are required by som= e drafts deemed by folks in the know then they are warranted. I think a con= sistent message is needed if you want to use Best path "Hole Punching" as a= rationale.. > Back to the persistence draft ... GR can address 90% of the > persistence draft requirements. [Jim U>] Disagree.. See my prior > note.. So what else is missing ? Propagation part that path is "suspicious" and=20 all routers in the given AFI/SAFI reachability in the Internet should=20 sort of dislike it ? Is that it ? [Jim U>] Internet?? I think that you need to realize that BGP is being used= for many different applications.. So, GR makes a decision in the internet = that a path is still valid even though a session went down. This is determi= nistic in that a decision has been made to not inform, Persistence allows a= customer to choose. There is a lot of value in this from a customer point = of view.. I think it would be great for all to understand the delta. So if this is=20 the delta I think in fact that Bruno who presented the draft is very=20 flexible in this space. Other co-authors I spoke with were not even aware some communities were=20 added to the draft like STALE ..... > Need to be careful when we use customer tools i.e LP to accomplish > provider goals. This type of approach may conflict with RFC1998.. Local pref is AS tool - not customer tool. It is not propagated across=20 AS boundaries. [Jim U>] Do not agree.. It has nothing to do with propagation across AS Bou= ndaries.. VPNV4 routing context belongs to the customer.. They use LP to ac= complish their routing designs in our network. RFC1998 is the agreed upon m= ethod.=20 Besides your STALE community already is said to overwrite any other=20 preference so I see completely no substantial point of your above comment. > Marking paths with CVs does not influence best path decision unless > policy is applied at every point. This is not a workable solution in > a large network Local pref is applied at every router as far as I know. STALE will also=20 not be magically enabled everywhere in the network till the network is=20 upgraded and knob is configured. Is this workable in large network ??? [Jim U>] Knob?? STALE is appended to a path when the session is was learned= over has been compromised, that path is then advertised.. Part of the impl= ementation.. > Also I think current -00 version has serious issues as already > pointed on the list. We need to wait till -01 is published in order > to see if those issues have been fixed. [Jim U>] Disagree.. I do > believe that the draft needs to evolve in how it deals with different > use cases and the peculiarities of each.. IMO the purpose of IETF > specifications is to provide tools for designers. We cannot take an > approach that we will not develop tools as designers may not > understand how to use them and could screw up their networks.. if > this is the approach then we probably need to retire lots of > technology that can be used incorrectly.. The argument that designers > can screw up their network is specious at best.. I think this proves you are missing the loop case I described in the=20 other email. It is fine to provide rope and count that you use it wisely=20 for climbing the cliff. [Jim U>] Your example although contrived does illustrate a case where a cus= tomer who does not understand the technology implements incorrectly.. Again= this can happen with many of the technologies as I mentioned before.. i.e = RT-Constrain, Addpath, etc.. So let's either be consistent in how much rope= is allotted for different technical enhancements or do away with it comple= tely.. We cannot have some drafts get lots of rope and other get some twine= .. However it is IMHO wrong thing to provide a tool which has no way of=20 working correctly ... in this particular case STALE CV across EBGP=20 session - simply as you as operator are not aware about your peers=20 topology and support of routing platform in their ASes. [Jim U>] I do not understand.. Why does it have no way of working correctly= ? Because someone implemented it incorrectly.. More importantly I want the = customers to know about the state of their VPN when it transits the routing= context they have purchased in our network.. Bruno offered to change this to G-SHUT which in turn is designed to be=20 mapped to local-pref. I have no problem with this approach. So you can=20 achieve exactly what you need safely. [Jim U>] We will consider all approaches.. To summarize .. I do recommend the same as Enke said at the mic .. It=20 would be much better to turn this current document into requirements=20 document so WG could provide opinions and proposals on how to solve them=20 (provided they are valid) rather then propose a solution and keep=20 arguing that this is the best one to solve your yet to be well defined=20 problem. [Jim U>] Do not agree.. The assumption that GR can be manipulated to accomp= lish the requirements is incorrect.. It is not right to select a solution t= hat has not before considered the requirements and then reverse engineer a = bottom up solution in attempt to patch it..=20 Best, R. From bashandy@cisco.com Tue Nov 15 10:00:18 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93DF91F0C41 for ; Tue, 15 Nov 2011 10:00:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7AKaxbNRuQPx for ; Tue, 15 Nov 2011 10:00:14 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 709C91F0C40 for ; Tue, 15 Nov 2011 10:00:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bashandy@cisco.com; l=1096; q=dns/txt; s=iport; t=1321380014; x=1322589614; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=uSKBLe7JuAQFvSatiWFgid3s0ryy6jeF54BtWox3TWw=; b=YWpwk64BH2V+Lx+XT9lHdm2BFiZHGqaNL7oPTBS0vfHPUAxby4UZhMlm YdfXdxG0vNEiRIwVX6/skVXLBri5Y+65Oo82hfnNDoWgZk47/6jUsIE/0 YjjoOtuPXkf33pker3OEtSql3JL+ZPpsURrPQAa33zK19Vqgwk16xQwaG s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsAAI6nwk6rRDoG/2dsb2JhbABDmWaQCIEFgXIBAQEEAQEBDwFbCgEMBAsRBAEBAQkWCAcJAwIBAgEVHwkIBg0BBQIBAR6HaJoDAZ5WBIoRBIgTjB+FRIxX X-IronPort-AV: E=Sophos;i="4.69,516,1315180800"; d="scan'208";a="14376125" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 15 Nov 2011 18:00:14 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAFI0EQp004212; Tue, 15 Nov 2011 18:00:14 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Nov 2011 10:00:14 -0800 Received: from dhcp-128-107-163-35.cisco.com ([128.107.163.35]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Nov 2011 10:00:13 -0800 Message-ID: <4EC2A8A7.1010202@cisco.com> Date: Tue, 15 Nov 2011 10:00:07 -0800 From: Ahmed Bashandy User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Shyam Sethuram (shsethur)" References: <4EAB1545.3000201@cisco.com> <404F0C7A-5866-46AA-BD99-767D865E9FFE@juniper.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Nov 2011 18:00:13.0521 (UTC) FILETIME=[6C6FB410:01CCA3C0] Cc: "Keyur Patel \(keyupate\)" , idr@ietf.org Subject: Re: [Idr] draft-keyur-idr-enhanced-gr-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 18:00:18 -0000 +++1 Support Ahmed On 11/14/11 6:04 PM, Shyam Sethuram (shsethur) wrote: > Support. > > thanks--shyam > > >> -----Original Message----- >> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of > John Scudder >> Sent: Friday, October 28, 2011 1:52 PM >> To: idr@ietf.org List >> Cc: Keyur Patel (keyupate) >> Subject: Re: [Idr] draft-keyur-idr-enhanced-gr-00.txt >> >> Folks, >> >> Please send comments to the list prior to the IDR meeting on November > 15. >> Thanks, >> >> --John >> >> On Oct 28, 2011, at 4:49 PM, Enke Chen wrote: >> >>> Hi, Sue and John: >>> >>> We would like to request that the following draft be adopted as an > IDR WR document: >>> draft-keyur-idr-enhanced-gr-00.txt >>> >>> It's presented at the last IETF. >>> >>> Thanks. -- Enke >>> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From robert@raszuk.net Tue Nov 15 18:03:24 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D376211E817D for ; Tue, 15 Nov 2011 18:03:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.733 X-Spam-Level: X-Spam-Status: No, score=-1.733 tagged_above=-999 required=5 tests=[AWL=0.866, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZScJocNyhM7 for ; Tue, 15 Nov 2011 18:03:23 -0800 (PST) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 9A31E11E815B for ; Tue, 15 Nov 2011 18:03:23 -0800 (PST) Received: (qmail 3800 invoked by uid 399); 16 Nov 2011 02:03:22 -0000 Received: from unknown (HELO ?10.0.1.3?) (130.129.67.115) by mail1310.opentransfer.com with ESMTP; 16 Nov 2011 02:03:22 -0000 X-Originating-IP: 130.129.67.115 Message-ID: <4EC319EA.7010801@raszuk.net> Date: Wed, 16 Nov 2011 03:03:22 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "UTTARO, JAMES" References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net> <4EA84254.9000400@raszuk.net> <4EA8A91C.4090305@cisco.com> <4EAA496C.9070605@cisco.com> <4EC21062.5020504@raszuk.net> <4EC28B45.1040509@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'idr@ietf.org List'" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 02:03:24 -0000 >[Jim U>] Ok so GR is still propagating some > path from a BGP session that went down or is compromised.. So what is > the point here? Ok for GR but not ok for Persistence?? GR is not propagating anything .. it is just not withdrawing nor re-advertising it for GR timer which is much much shorter anyway then what persistent draft calls as a examples of timer. Side note: If the BGP is used for pushing configuration information which are stable and should stay in the network till operator decides to remove it - regardless of session state they were distributed by - I have no problem with that. However I am of the opinion that to accomplish that you should not just stuck new community and re-advertise when the session goes down. You should up front advertise such routes with either persistent community or perhaps new SAFI capability flag. Thx, R. From russw@riw.us Tue Nov 15 19:21:36 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56F2611E80C7 for ; Tue, 15 Nov 2011 19:21:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jByhMBG40RzO for ; Tue, 15 Nov 2011 19:21:35 -0800 (PST) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id DBBB311E809C for ; Tue, 15 Nov 2011 19:21:35 -0800 (PST) Received: from [107.17.45.77] (port=49807) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RQW45-00029h-8W; Tue, 15 Nov 2011 22:21:33 -0500 Message-ID: <4EC32C36.8070902@riw.us> Date: Tue, 15 Nov 2011 22:21:26 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: robert@raszuk.net References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net> <4EA84254.9000400@raszuk.net> <4EA8A91C.4090305@cisco.com> <4EAA496C.9070605@cisco.com> <4EC21062.5020504@raszuk.net> <4EC28B45.1040509@raszuk.net> In-Reply-To: <4EC28B45.1040509@raszuk.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Cc: "'idr@ietf.org List'" , "UTTARO, JAMES" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 03:21:36 -0000 > I am personally completely not convinced that there is any value in > informing my peers that one of my BGP sessions went down. You either > have reachability to next hop and can attract traffic or you do not and > if so you withdraw. > > Telling peers that "I may be perhaps used to reach prefix X as last > resort" is of highly questionable value. I would go farther --this isn't questionable, it's really bad. If you have a route you know exists, but you don't want people to use, set things so it's a "last resort" (wait for BGP, wait for LDP, etc). If you don't know whether or not you really have reachability, don't advertise it. The possible problems involved in saying, "I might have a route to x, just in case you don't have any other path there," will end up being really, really ugly. :-) Russ From jgs@juniper.net Tue Nov 15 22:38:18 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B113A11E8192 for ; Tue, 15 Nov 2011 22:38:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.526 X-Spam-Level: X-Spam-Status: No, score=-6.526 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QHhXwf7f7Vs for ; Tue, 15 Nov 2011 22:38:18 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id F1F1E11E818C for ; Tue, 15 Nov 2011 22:38:17 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTsNaWRKiwWq/sP+gzKaFuk/5sjaai8tY@postini.com; Tue, 15 Nov 2011 22:38:18 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Tue, 15 Nov 2011 22:36:51 -0800 From: John Scudder To: "idr@ietf.org List" Date: Tue, 15 Nov 2011 22:36:52 -0800 Thread-Topic: Adoption of draft-jasinska-ix-bgp-route-server-03 as IDR WG document? Thread-Index: AcykKh97kHpl4oYwTB6MrSZ7j/kTXg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Idr] Adoption of draft-jasinska-ix-bgp-route-server-03 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: Wed, 16 Nov 2011 06:38:18 -0000 Folks, We have received a request from the authors to adopt draft-jasinska-ix-bgp-= route-server-03 as an IDR WG document. Please send your comments to the li= st. The deadline for comments is December 5, 2011 at noon EST. Thanks, --John= From jgs@juniper.net Wed Nov 16 01:04:08 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4A721F94D4 for ; Wed, 16 Nov 2011 01:04:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.529 X-Spam-Level: X-Spam-Status: No, score=-6.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpNIuUuPZ6Fw for ; Wed, 16 Nov 2011 01:04:08 -0800 (PST) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id E8FCA21F9479 for ; Wed, 16 Nov 2011 01:04:07 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTsN8h3eJvRJXsmwrgpWqMfR7MqvgYerR@postini.com; Wed, 16 Nov 2011 01:04:07 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 16 Nov 2011 01:01:58 -0800 From: John Scudder To: "idr@ietf.org List" Date: Wed, 16 Nov 2011 01:01:57 -0800 Thread-Topic: Adoption of ft-zeng-idr-bgp-mtu-extension-01 as IDR WG document? Thread-Index: AcykPmVa8LWoAk9KTsSbEqY4GZMTUQ== Message-ID: <9B76DC1E-7F59-4E07-B90D-762A173B8C82@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Idr] Adoption of ft-zeng-idr-bgp-mtu-extension-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: Wed, 16 Nov 2011 09:04:08 -0000 Folks, We have received a request from the authors to adopt ft-zeng-idr-bgp-mtu-ex= tension-01 as an IDR WG document. Please send your comments to the list. = The deadline for comments is December 5, 2011 at noon EST. Thanks, --John= From jgs@juniper.net Wed Nov 16 01:04:08 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C58B621F9479 for ; Wed, 16 Nov 2011 01:04:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.533 X-Spam-Level: X-Spam-Status: No, score=-6.533 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ot0eNuDAq55t for ; Wed, 16 Nov 2011 01:04:08 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 2551D21F947C for ; Wed, 16 Nov 2011 01:04:08 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTsN8blWhcTy+vZUiLjE4OkuUTUOjBymz@postini.com; Wed, 16 Nov 2011 01:04:08 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 16 Nov 2011 01:01:12 -0800 From: John Scudder To: "idr@ietf.org List" Date: Wed, 16 Nov 2011 01:01:11 -0800 Thread-Topic: Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document? Thread-Index: AcykPkoZv0rjpQtASsSyYlxRDSuk7A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 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: Wed, 16 Nov 2011 09:04:08 -0000 Folks, We have received a request from the authors to adopt draft-l3vpn-legacy-rtc= -00 as an IDR WG document. Please send your comments to the list. The dea= dline for comments is December 5, 2011 at noon EST. Thanks, --John= From jgs@juniper.net Wed Nov 16 01:11:42 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31D0E21F9514 for ; Wed, 16 Nov 2011 01:11:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.536 X-Spam-Level: X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WzqWMUvgKli for ; Wed, 16 Nov 2011 01:11:39 -0800 (PST) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 83C3321F9590 for ; Wed, 16 Nov 2011 01:11:38 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKTsN+RmQoijaMF6eSVVY1XjSj032rrV2o@postini.com; Wed, 16 Nov 2011 01:11:38 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Wed, 16 Nov 2011 01:06:20 -0800 From: John Scudder To: "idr@ietf.org List" Date: Wed, 16 Nov 2011 01:06:19 -0800 Thread-Topic: Adoption of draft-varlashkin-bgp-nh-cost-02 as IDR WG document? Thread-Index: AcykPwG7jl6Kwgf+R0CL/omsorSMmQ== Message-ID: <7B61DC70-08D9-46C7-8C15-5DD339C61C2D@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Idr] Adoption of draft-varlashkin-bgp-nh-cost-02 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: Wed, 16 Nov 2011 09:11:42 -0000 Folks, We have received a request from the authors to adopt draft-varlashkin-bgp-n= h-cost-02 as an IDR WG document. Please send your comments to the list. T= he deadline for comments is December 5, 2011 at noon EST. Thanks, --John= From khuon@neebu.net Wed Nov 16 01:45:07 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2ED21F95F6 for ; Wed, 16 Nov 2011 01:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRt2Ig9rAuBM for ; Wed, 16 Nov 2011 01:45:06 -0800 (PST) Received: from Decaf.NEEBU.Net (decaf.neebu.net [66.166.158.133]) by ietfa.amsl.com (Postfix) with ESMTP id B133A21F95F2 for ; Wed, 16 Nov 2011 01:45:04 -0800 (PST) Received: from [127.0.0.1] (khuon@Decaf.NEEBU.Net [127.0.0.1]) by Decaf.NEEBU.Net (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pAG8AI5J000551; Wed, 16 Nov 2011 00:10:18 -0800 From: Jake Khuon To: John Scudder In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Organization: NEEBU Networks, Assoc. Date: Wed, 16 Nov 2011 00:10:17 -0800 Message-ID: <1321431017.28268.6.camel@Decaf.NEEBU.Net> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-jasinska-ix-bgp-route-server-03 as IDR WG document? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: khuon@neebu.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 09:45:07 -0000 On Tue, 2011-11-15 at 22:36 -0800, John Scudder wrote: > We have received a request from the authors to adopt > draft-jasinska-ix-bgp-route-server-03 as an IDR WG document. Please > send your comments to the list. The deadline for comments is December > 5, 2011 at noon EST. I would support adoption of this draft by the working group. -- /*=================[ Jake Khuon ]=================+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | -------- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| NETWORKS | +==================================================================*/ From hannes@juniper.net Wed Nov 16 01:56:35 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1F3321F962F for ; Wed, 16 Nov 2011 01:56:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekYJa9gTJMtq for ; Wed, 16 Nov 2011 01:56:35 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 4319321F962E for ; Wed, 16 Nov 2011 01:56:35 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTsOI0oP784MFfnKEDyjoRQEIdggDxIwV@postini.com; Wed, 16 Nov 2011 01:56:35 PST Received: from [172.23.3.231] (172.23.3.231) by smtp.juniper.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 16 Nov 2011 01:51:26 -0800 Message-ID: <4EC3883F.3060602@juniper.net> Date: Wed, 16 Nov 2011 10:54:07 +0100 From: Hannes Gredler User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: John Scudder References: <9B76DC1E-7F59-4E07-B90D-762A173B8C82@juniper.net> In-Reply-To: <9B76DC1E-7F59-4E07-B90D-762A173B8C82@juniper.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of ft-zeng-idr-bgp-mtu-extension-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: Wed, 16 Nov 2011 09:56:36 -0000 no support - IMO its not needed as a router could send the PMTU/ICMP message in the downstream direction where a LSP egress node decapsulates the packet and finally sends it back to the ingress node; we are doing this successfully for other labeled environments, so i fail to see why LBGP is different in that respect. tx, /hannes On 11/16/2011 10:01 AM, John Scudder wrote: > Folks, > > We have received a request from the authors to adopt ft-zeng-idr-bgp-mtu-extension-01 as an IDR WG document. Please send your comments to the list. The deadline for comments is December 5, 2011 at noon EST. > > Thanks, > > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From rjs@rob.sh Wed Nov 16 02:31:05 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0D921F956C for ; Wed, 16 Nov 2011 02:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HxQuaQO8cuj for ; Wed, 16 Nov 2011 02:31:05 -0800 (PST) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id 1916921F9564 for ; Wed, 16 Nov 2011 02:31:05 -0800 (PST) Received: from [93.97.180.64] (helo=latte.config) by cappuccino.rob.sh with esmtpa (Exim 4.69) (envelope-from ) id 1RQcjp-0002za-VV; Wed, 16 Nov 2011 10:29:06 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Rob Shakir In-Reply-To: Date: Wed, 16 Nov 2011 10:31:02 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: John Scudder X-Mailer: Apple Mail (2.1084) Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-jasinska-ix-bgp-route-server-03 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: Wed, 16 Nov 2011 10:31:05 -0000 On 16 Nov 2011, at 06:36, John Scudder wrote: > Folks, >=20 > We have received a request from the authors to adopt = draft-jasinska-ix-bgp-route-server-03 as an IDR WG document. Please = send your comments to the list. The deadline for comments is December = 5, 2011 at noon EST. Hi John, IDR, This work is exceedingly useful to document the functionality of route = servers, which continue to grow in importance in IXP deployments. I = would therefore support the document's adoption by IDR. Kind regards, r.= From ju1738@att.com Wed Nov 16 04:27:00 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECDD721F9481 for ; Wed, 16 Nov 2011 04:27:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.178 X-Spam-Level: X-Spam-Status: No, score=-106.178 tagged_above=-999 required=5 tests=[AWL=0.421, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sA9egh39pQ0M for ; Wed, 16 Nov 2011 04:27:00 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 4168921F947B for ; Wed, 16 Nov 2011 04:27:00 -0800 (PST) X-Env-Sender: ju1738@att.com X-Msg-Ref: server-2.tower-119.messagelabs.com!1321446418!1292459!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28742 invoked from network); 16 Nov 2011 12:26:58 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-2.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Nov 2011 12:26:58 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pAGCRQNb029514; Wed, 16 Nov 2011 07:27:26 -0500 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pAGCRJJi029478 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Nov 2011 07:27:19 -0500 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([169.254.1.53]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.01.0339.001; Wed, 16 Nov 2011 07:26:51 -0500 From: "UTTARO, JAMES" To: "'robert@raszuk.net'" Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-00 Thread-Index: AQHMkEAnLP0iAkRlVkChUYWtkZqOMZWKuQoAgAQhplCAAIdcwoABIPrwgAESmgCABpCw8IAVN//QgACgTgCAAB3Q8IAAdK6A//+wnNCAAPlwAIAAWJ4Q Date: Wed, 16 Nov 2011 12:26:50 +0000 Message-ID: References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net> <4EA84254.9000400@raszuk.net> <4EA8A91C.4090305@cisco.com> <4EAA496C.9070605@cisco.com> <4EC21062.5020504@raszuk.net> <4EC28B45.1040509@raszuk.net> <4EC319EA.7010801@raszuk.net> In-Reply-To: <4EC319EA.7010801@raszuk.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.253.123] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'idr@ietf.org List'" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 12:27:01 -0000 Robert, Comments In-Line.. Jim Uttaro -----Original Message----- From: Robert Raszuk [mailto:robert@raszuk.net]=20 Sent: Tuesday, November 15, 2011 9:03 PM To: UTTARO, JAMES Cc: 'Enke Chen'; 'idr@ietf.org List' Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 >[Jim U>] Ok so GR is still propagating some > path from a BGP session that went down or is compromised.. So what is > the point here? Ok for GR but not ok for Persistence?? GR is not propagating anything .. it is just not withdrawing nor=20 re-advertising it for GR timer which is much much shorter anyway then=20 what persistent draft calls as a examples of timer. [Jim U>] Ok.. let me be clearer.. Due to the fact that GR is "not" withdraw= ing a path that was learned over a session which may be compromised that pa= th is still valid in the routing topology.. The difference between GR and P= ersistence is that GR does not provide the ability to inform the topology t= hat the path is of questionable value..=20 Side note: If the BGP is used for pushing configuration information which are=20 stable and should stay in the network till operator decides to remove it=20 - regardless of session state they were distributed by - I have no=20 problem with that. However I am of the opinion that to accomplish that you should not just=20 stuck new community and re-advertise when the session goes down. You=20 should up front advertise such routes with either persistent community=20 or perhaps new SAFI capability flag. [Jim U>] Read the Draft... The PERSIST community is attached up front.. In = fact that identification is used when the session goes down, at the point t= he STALE CV is set and paths re-advertised.. "2.1. PERSIST This memo defines a new transitive BGP community, PERSIST, with value TBD (to be assigned by IANA). Attaching of the PERSIST community SHOULD be controlled by configuration. Attaching the PERSIST community indicates that the peer should maintain forwarding in the case of a session failure. The functionality SHOULD default to being disabled. " Thx, R. From jie.dong@huawei.com Wed Nov 16 05:41:13 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60C521F0C4B for ; Wed, 16 Nov 2011 05:41:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.413 X-Spam-Level: X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90K1u0bg54ct for ; Wed, 16 Nov 2011 05:41:12 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 83BAC1F0C36 for ; Wed, 16 Nov 2011 05:41:12 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUR00KKO9ZVA1@szxga04-in.huawei.com> for idr@ietf.org; Wed, 16 Nov 2011 21:40:43 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUR00KSD9ZVPC@szxga04-in.huawei.com> for idr@ietf.org; Wed, 16 Nov 2011 21:40:43 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFA65613; Wed, 16 Nov 2011 21:40:42 +0800 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 16 Nov 2011 21:40:37 +0800 Received: from SZXEML509-MBS.china.huawei.com ([169.254.2.220]) by szxeml411-hub.china.huawei.com ([10.82.67.138]) with mapi id 14.01.0323.003; Wed, 16 Nov 2011 21:40:33 +0800 Date: Wed, 16 Nov 2011 13:40:32 +0000 From: Jie Dong In-reply-to: <4EC3883F.3060602@juniper.net> X-Originating-IP: [172.24.2.40] To: Hannes Gredler , John Scudder Message-id: <76CD132C3ADEF848BD84D028D243C92722A19519@szxeml509-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [Idr] Adoption of ft-zeng-idr-bgp-mtu-extension-01 as IDR WG document? Thread-index: AQHMpEY3Sgk2SNst70+U8vVsP9itSpWvdody X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <9B76DC1E-7F59-4E07-B90D-762A173B8C82@juniper.net> <4EC3883F.3060602@juniper.net> Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of ft-zeng-idr-bgp-mtu-extension-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: Wed, 16 Nov 2011 13:41:13 -0000 Hi Hannes, Thanks for your comment. Could you help provide in which document is this solution specified? RFC1191(PMTU discovery) says: "It is expected that future routing protocols will be able to provide accurate PMTU information within a routing area..." And since as we know other label sigaling protocols have defined the control plane based MTU discovery, it would be reasonble to also have this mechanism for labeled bgp. Also for some inter-AS scenarios data plane MTU discovery mechanism may not be allowed. Regards, Jie ________________________________________ From: idr-bounces@ietf.org [idr-bounces@ietf.org] on behalf of Hannes Gredler [hannes@juniper.net] Sent: Wednesday, November 16, 2011 17:54 To: John Scudder Cc: idr@ietf.org List Subject: Re: [Idr] Adoption of ft-zeng-idr-bgp-mtu-extension-01 as IDR WG document? no support - IMO its not needed as a router could send the PMTU/ICMP message in the downstream direction where a LSP egress node decapsulates the packet and finally sends it back to the ingress node; we are doing this successfully for other labeled environments, so i fail to see why LBGP is different in that respect. tx, /hannes On 11/16/2011 10:01 AM, John Scudder wrote: > Folks, > > We have received a request from the authors to adopt ft-zeng-idr-bgp-mtu-extension-01 as an IDR WG document. Please send your comments to the list. The deadline for comments is December 5, 2011 at noon EST. > > Thanks, > > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From ilya@nobulus.com Wed Nov 16 06:02:58 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A456121F9470 for ; Wed, 16 Nov 2011 06:02:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[AWL=-0.648, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zjYSD4GZ1Zb for ; Wed, 16 Nov 2011 06:02:46 -0800 (PST) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by ietfa.amsl.com (Postfix) with ESMTP id BBB9921F96BA for ; Wed, 16 Nov 2011 06:02:45 -0800 (PST) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id DFF0F174DE; Wed, 16 Nov 2011 15:02:44 +0100 (CET) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id kjL7D+EKw-lS; Wed, 16 Nov 2011 15:02:39 +0100 (CET) Received: from [192.168.142.198] (60-251-179-224.HINET-IP.hinet.net [60.251.179.224]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by nobulus.com (Postfix) with ESMTPSA id 007D9174EB; Wed, 16 Nov 2011 15:02:38 +0100 (CET) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <12D36CE0-B004-43A6-A069-5F6FCAE7F9D9@nobulus.com> X-Mailer: iPhone Mail (9A405) From: Ilya Varlashkin Date: Wed, 16 Nov 2011 22:02:59 +0800 To: John Scudder Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 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: Wed, 16 Nov 2011 14:02:59 -0000 Support /iLya On 16 Nov 2011, at 17:01, John Scudder wrote: > Folks, >=20 > We have received a request from the authors to adopt draft-l3vpn-legacy-rt= c-00 as an IDR WG document. Please send your comments to the list. The dea= dline for comments is December 5, 2011 at noon EST. >=20 > Thanks, >=20 > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 From rjs@rob.sh Wed Nov 16 06:34:58 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92A6F11E80E9 for ; Wed, 16 Nov 2011 06:34:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZNM3MBF4fNb for ; Wed, 16 Nov 2011 06:34:58 -0800 (PST) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id 038CF11E80E1 for ; Wed, 16 Nov 2011 06:34:57 -0800 (PST) Received: from [93.97.180.64] (helo=latte.config) by cappuccino.rob.sh with esmtpa (Exim 4.69) (envelope-from ) id 1RQgXm-0003vg-O6; Wed, 16 Nov 2011 14:32:54 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Rob Shakir In-Reply-To: Date: Wed, 16 Nov 2011 14:34:50 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <98DC36B6-460D-4039-AD69-D8EB2A430957@rob.sh> References: To: John Scudder X-Mailer: Apple Mail (2.1084) Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 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: Wed, 16 Nov 2011 14:34:58 -0000 On 16 Nov 2011, at 09:01, John Scudder wrote: > Folks, >=20 > We have received a request from the authors to adopt = draft-l3vpn-legacy-rtc-00 as an IDR WG document. Please send your = comments to the list. The deadline for comments is December 5, 2011 at = noon EST. Hi John, IDR, I support adopting this draft as an IDR WG document. Kind regards, r.= From ju1738@att.com Wed Nov 16 06:54:26 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F11511E8106 for ; Wed, 16 Nov 2011 06:54:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.211 X-Spam-Level: X-Spam-Status: No, score=-106.211 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Qob61wlIp1w for ; Wed, 16 Nov 2011 06:54:20 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE8E21F963B for ; Wed, 16 Nov 2011 06:54:20 -0800 (PST) X-Env-Sender: ju1738@att.com X-Msg-Ref: server-2.tower-119.messagelabs.com!1321455257!1312744!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14501 invoked from network); 16 Nov 2011 14:54:18 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-2.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Nov 2011 14:54:18 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pAGEsjFD025449; Wed, 16 Nov 2011 09:54:45 -0500 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pAGEsctO025023 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Nov 2011 09:54:38 -0500 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([169.254.1.53]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.01.0339.001; Wed, 16 Nov 2011 09:54:10 -0500 From: "UTTARO, JAMES" To: "'Rob Shakir'" , John Scudder Thread-Topic: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document? Thread-Index: AcykPkoZv0rjpQtASsSyYlxRDSuk7AAWIQwAAAnPTaA= Date: Wed, 16 Nov 2011 14:54:09 +0000 Message-ID: References: <98DC36B6-460D-4039-AD69-D8EB2A430957@rob.sh> In-Reply-To: <98DC36B6-460D-4039-AD69-D8EB2A430957@rob.sh> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.253.123] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 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: Wed, 16 Nov 2011 14:54:26 -0000 +1 Jim Uttaro -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Rob S= hakir Sent: Wednesday, November 16, 2011 9:35 AM To: John Scudder Cc: idr@ietf.org List Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document= ? On 16 Nov 2011, at 09:01, John Scudder wrote: > Folks, >=20 > We have received a request from the authors to adopt draft-l3vpn-legacy-r= tc-00 as an IDR WG document. Please send your comments to the list. The d= eadline for comments is December 5, 2011 at noon EST. Hi John, IDR, I support adopting this draft as an IDR WG document. Kind regards, r. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From gaurab@lahai.com Wed Nov 16 07:27:25 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C65B321F9466 for ; Wed, 16 Nov 2011 07:27:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOv4J6vkdIui for ; Wed, 16 Nov 2011 07:27:24 -0800 (PST) Received: from pao.lahai.com (unknown [206.220.230.130]) by ietfa.amsl.com (Postfix) with ESMTP id 0732021F945F for ; Wed, 16 Nov 2011 07:27:23 -0800 (PST) Received: from Gaurabs-MacBook-Pro.local (cm7.epsilon121.maxonline.com.sg [222.164.121.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gaurab) by pao.lahai.com (Postfix) with ESMTP id 6287EB302B for ; Wed, 16 Nov 2011 15:27:12 +0000 (UTC) Message-ID: <4EC3D64D.30600@lahai.com> Date: Wed, 16 Nov 2011 15:27:09 +0000 From: Gaurab Raj Upadhaya User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: idr@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Idr] Adoption of draft-jasinska-ix-bgp-route-server-03 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: Wed, 16 Nov 2011 15:27:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I support the adoption of this draft. - -gaurab (APIX/NPIX) On 11/16/11 6:36 AM, John Scudder wrote: > Folks, > > We have received a request from the authors to adopt > draft-jasinska-ix-bgp-route-server-03 as an IDR WG document. > Please send your comments to the list. The deadline for comments > is December 5, 2011 at noon EST. > > Thanks, > > --John _______________________________________________ Idr mailing > list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr - -- http://www.gaurab.org.np/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7D1k0ACgkQSo7fU26F3X17UACbBLCgnZYB7wJ30ACOTuF3SVWb +VgAoK4sU2EX1kMhjgBx7P10Dwbdv/ud =F7Sj -----END PGP SIGNATURE----- From jeff.tantsura@ericsson.com Wed Nov 16 07:29:57 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8277321F9496 for ; Wed, 16 Nov 2011 07:29:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UpSsQGn4jjmb for ; Wed, 16 Nov 2011 07:29:56 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id A29D121F9467 for ; Wed, 16 Nov 2011 07:29:56 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id pAGFTtl1022349 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Nov 2011 09:29:56 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.111]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 16 Nov 2011 10:29:55 -0500 From: Jeff Tantsura To: John Scudder Date: Wed, 16 Nov 2011 10:30:04 -0500 Thread-Topic: [Idr] Adoption of draft-jasinska-ix-bgp-route-server-03 as IDR WG document? Thread-Index: AcykdJc8DAY5qPkjStquQ3UxzIMhZw== Message-ID: <0AD9033C-58E8-42F0-B56E-5FF8E0A3DCAD@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-jasinska-ix-bgp-route-server-03 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: Wed, 16 Nov 2011 15:29:57 -0000 Yes/support - has become a really solid document. Regards, Jeff On Nov 16, 2011, at 2:39 PM, "John Scudder" wrote: > Folks, >=20 > We have received a request from the authors to adopt draft-jasinska-ix-bg= p-route-server-03 as an IDR WG document. Please send your comments to the = list. The deadline for comments is December 5, 2011 at noon EST. >=20 > Thanks, >=20 > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From brian.peter.dickson@gmail.com Wed Nov 16 07:47:01 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B019411E80AB for ; Wed, 16 Nov 2011 07:47:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.486 X-Spam-Level: X-Spam-Status: No, score=-3.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEljabvFxPhb for ; Wed, 16 Nov 2011 07:47:01 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id A540C11E8095 for ; Wed, 16 Nov 2011 07:46:57 -0800 (PST) Received: by bkbzv15 with SMTP id zv15so860759bkb.31 for ; Wed, 16 Nov 2011 07:46:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=jkRW8jBVrVwKj1mFh/Io0lKjQkFSYA9mPDbWGPgD+N0=; b=pb3fZbHk7DDPt2KE1alk5cYAbdGQGkFYqOC8kXbujEP0n90ZCJdJDMIUzpb++aFr4e nbkmIR024r26rrAwGSxMN3dR+I9X/xOEaJrbcF9fK8s6CCy+9h22Cjw7+MTW0j7U2II7 xm+g5IkSyXgu/C1OpqAiO6s6GTQbcOFwndz+M= MIME-Version: 1.0 Received: by 10.204.7.133 with SMTP id d5mr29742025bkd.64.1321458416742; Wed, 16 Nov 2011 07:46:56 -0800 (PST) Received: by 10.223.54.15 with HTTP; Wed, 16 Nov 2011 07:46:56 -0800 (PST) In-Reply-To: References: Date: Wed, 16 Nov 2011 10:46:56 -0500 Message-ID: From: Brian Dickson To: John Scudder Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-jasinska-ix-bgp-route-server-03 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: Wed, 16 Nov 2011 15:47:01 -0000 Support On Wed, Nov 16, 2011 at 1:36 AM, John Scudder wrote: > Folks, > > We have received a request from the authors to adopt draft-jasinska-ix-bg= p-route-server-03 as an IDR WG document. =A0Please send your comments to th= e list. =A0The deadline for comments is December 5, 2011 at noon EST. > > Thanks, > > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From stephane.litkowski@orange.com Wed Nov 16 06:48:59 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B80821F9613 for ; Wed, 16 Nov 2011 06:48:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLW2FwcLidVE for ; Wed, 16 Nov 2011 06:48:58 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 5E18E11E8103 for ; Wed, 16 Nov 2011 06:48:58 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 2D5C42647D1; Wed, 16 Nov 2011 15:48:57 +0100 (CET) Received: from PUEXCC51.nanterre.francetelecom.fr (unknown [10.168.74.61]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 04E0135C05B; Wed, 16 Nov 2011 15:48:57 +0100 (CET) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.46]) by PUEXCC51.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Nov 2011 15:48:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Nov 2011 15:48:55 +0100 Message-ID: <6017_1321454937_4EC3CD59_6017_21758_1_4FC3556A36EE3646A09DAA60429F533507492286@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document? Thread-Index: AcykPkoZv0rjpQtASsSyYlxRDSuk7AAMGI2w References: From: To: "John Scudder" , X-OriginalArrivalTime: 16 Nov 2011 14:48:57.0311 (UTC) FILETIME=[DE7EC6F0:01CCA46E] X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.11.16.130326 X-Mailman-Approved-At: Wed, 16 Nov 2011 08:14:11 -0800 Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 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: Wed, 16 Nov 2011 14:50:01 -0000 Support ! -- Stephane =20=20 -----Message d'origine----- De : idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] De la part de John = Scudder Envoy=E9 : mercredi 16 novembre 2011 10:01 =C0 : idr@ietf.org List Objet : [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document? Folks, We have received a request from the authors to adopt draft-l3vpn-legacy-rtc= -00 as an IDR WG document. Please send your comments to the list. The dea= dline for comments is December 5, 2011 at noon EST. Thanks, --John _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration,=20 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;=20 they should not be distributed, used or copied without authorization. If you have received this email in error, please notify the sender and dele= te this message and its attachments.=20 As emails may be altered, France Telecom - Orange shall not be liable if th= is message was modified, changed or falsified. Thank you. From robert@raszuk.net Wed Nov 16 08:40:30 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 111FA11E80A2 for ; Wed, 16 Nov 2011 08:40:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.714 X-Spam-Level: X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[AWL=0.885, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8eh+g7VsUAS for ; Wed, 16 Nov 2011 08:40:29 -0800 (PST) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id E225B11E8085 for ; Wed, 16 Nov 2011 08:40:28 -0800 (PST) Received: (qmail 13587 invoked by uid 399); 16 Nov 2011 16:40:28 -0000 Received: from unknown (HELO ?10.0.1.3?) (130.129.67.115) by mail1310.opentransfer.com with ESMTP; 16 Nov 2011 16:40:28 -0000 X-Originating-IP: 130.129.67.115 Message-ID: <4EC3E77B.7080100@raszuk.net> Date: Wed, 16 Nov 2011 17:40:27 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "UTTARO, JAMES" References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net> <4EA84254.9000400@raszuk.net> <4EA8A91C.4090305@cisco.com> <4EAA496C.9070605@cisco.com> <4EC21062.5020504@raszuk.net> <4EC28B45.1040509@raszuk.net> <4EC319EA.7010801@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'idr@ietf.org List'" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 16:40:30 -0000 Jim, > The difference between > GR and Persistence is that GR does not provide the ability to inform > the topology that the path is of questionable value.. You are apparently missing many pieces ... GR maintains the routes .. but GR does not overwrite NHT (Next Hop Tracking) ... that means that path's next hop is still valid. Persistent draft however re-advertises routes as STALE without per spec any considerations of the next hop liveness. That is bad ! >[Jim U>] Read the > Draft... The PERSIST community is attached up front.. In fact that > identification is used when the session goes down, at the point the > STALE CV is set and paths re-advertised.. You are persistently missing the point. My point was to mark the paths as persistent up front meaning keep them regardless of session state which they were received on. No need for any stale cv at all. As I and others already explicitly said on the list re-advertising the paths with a marker you may use me as last resort is just a terrible idea. Best regards, R. From robert@raszuk.net Wed Nov 16 08:48:45 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5078811E80B7 for ; Wed, 16 Nov 2011 08:48:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.862 X-Spam-Level: X-Spam-Status: No, score=-1.862 tagged_above=-999 required=5 tests=[AWL=0.737, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Md+2xEy8R+Jk for ; Wed, 16 Nov 2011 08:48:40 -0800 (PST) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 6159A11E8085 for ; Wed, 16 Nov 2011 08:48:40 -0800 (PST) Received: (qmail 19158 invoked by uid 399); 16 Nov 2011 16:48:39 -0000 Received: from unknown (HELO ?10.0.1.3?) (130.129.67.115) by mail1310.opentransfer.com with ESMTP; 16 Nov 2011 16:48:39 -0000 X-Originating-IP: 130.129.67.115 Message-ID: <4EC3E968.4060709@raszuk.net> Date: Wed, 16 Nov 2011 17:48:40 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "idr@ietf.org List" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 16:48:45 -0000 If authors agree to provide the addition to the draft that all RRs in a given network should support this extension before it is enabled I support this draft. However one needs to understand that this extension means new code on RR as well as modification to current PE provisioning script(s). Best regards, R. > Folks, > > We have received a request from the authors to adopt > draft-l3vpn-legacy-rtc-00 as an IDR WG document. Please send your > comments to the list. The deadline for comments is December 5, 2011 > at noon EST. > > Thanks, > > --John _______________________________________________ Idr mailing > list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr > > From pedro.r.marques@gmail.com Wed Nov 16 09:19:04 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F19721F9474 for ; Wed, 16 Nov 2011 09:19:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.944 X-Spam-Level: X-Spam-Status: No, score=-2.944 tagged_above=-999 required=5 tests=[AWL=0.655, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8sxf6gJDa8P for ; Wed, 16 Nov 2011 09:19:01 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0AAA721F9471 for ; Wed, 16 Nov 2011 09:19:00 -0800 (PST) Received: by iaeo4 with SMTP id o4so1100825iae.31 for ; Wed, 16 Nov 2011 09:19:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=v6UrvpzWWb/YzMLolHx8x/51TzVL+EkwAY3+qHHc8YM=; b=rzZsbsMnDFvin+aTDU+TsfgwBr7SyAsKoU1NkCbQyO/XO3/zdv70Zia/cpIGM6Tqbx Zup5l/MGRkx+xjTKScPYACsINjqgvISMa0bTnklesp52vr+SaK3nB7vZtrR+qNvDlhIM TSzMl0CWSX3BpSzvb6yJQhUxMyMGLor/X+HpE= MIME-Version: 1.0 Received: by 10.231.8.143 with SMTP id h15mr7455034ibh.94.1321463940578; Wed, 16 Nov 2011 09:19:00 -0800 (PST) Received: by 10.231.12.2 with HTTP; Wed, 16 Nov 2011 09:19:00 -0800 (PST) In-Reply-To: References: Date: Wed, 16 Nov 2011 09:19:00 -0800 Message-ID: From: Pedro Marques To: John Scudder Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 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: Wed, 16 Nov 2011 17:19:04 -0000 -1 I believe that the "legacy" is now the fact that rt-constraint is supported by the most common implementations. The proposed procedures for legacy PEs have a level of complexity that seems significantly higher than qualifying a new software release. Pedro. On Wed, Nov 16, 2011 at 1:01 AM, John Scudder wrote: > Folks, > > We have received a request from the authors to adopt draft-l3vpn-legacy-r= tc-00 as an IDR WG document. =A0Please send your comments to the list. =A0T= he deadline for comments is December 5, 2011 at noon EST. > > Thanks, > > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From rjs@rob.sh Wed Nov 16 10:20:36 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C21721F94D1 for ; Wed, 16 Nov 2011 10:20:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKgSttwFKLAl for ; Wed, 16 Nov 2011 10:20:35 -0800 (PST) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id 939EF21F94B5 for ; Wed, 16 Nov 2011 10:20:35 -0800 (PST) Received: from [93.97.180.64] (helo=latte.config) by cappuccino.rob.sh with esmtpa (Exim 4.69) (envelope-from ) id 1RQk4A-0004he-QX; Wed, 16 Nov 2011 18:18:34 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Rob Shakir In-Reply-To: Date: Wed, 16 Nov 2011 18:20:30 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Pedro Marques X-Mailer: Apple Mail (2.1084) Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 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: Wed, 16 Nov 2011 18:20:36 -0000 On 16 Nov 2011, at 17:19, Pedro Marques wrote: > -1 >=20 > I believe that the "legacy" is now the fact that rt-constraint is > supported by the most common implementations. >=20 > The proposed procedures for legacy PEs have a level of complexity that > seems significantly higher than qualifying a new software release. While this if of course a valid argument, I believe that there are some = operational constraints that make this untrue.=20 In an ideal world, all deployed PEs would be running current hardware, = and with software trains under active development. Unfortunately, this = is not always the case - and hence the requirement is more than a = software qualification to support RTC. The options here are migration to = new hardware platforms, which comes with significant operational costs, = or put up with some operational complexity to better utilise existing = assets whilst allowing network growth elsewhere, and delay expenditure.=20= I realise that such non-technical requirements may fall outside of the = consideration of IETF working groups - but I feel strongly that there is = some trade-off to be made that sacrifices some absolute correctness to = provide technologies that allow operators to meet their network's = commercial requirements.=20 We should (of course) consider the extent to which such compromises = compromise network robustness - but I can't say that I agree that this = draft upsets the complexity/benefit balance. I would be interested to = hear if you do. Kind regards, r. From david.freedman@uk.clara.net Wed Nov 16 10:21:24 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B195511E808E for ; Wed, 16 Nov 2011 10:21:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.047 X-Spam-Level: X-Spam-Status: No, score=-1.047 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5NRgde-2MZG for ; Wed, 16 Nov 2011 10:21:23 -0800 (PST) Received: from staff00.mail.eu.clara.net (staff00.mail.eu.clara.net [IPv6:2001:a88:0:fff7::68]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC3011E808C for ; Wed, 16 Nov 2011 10:21:23 -0800 (PST) Received: from [195.157.10.59] (port=17927 helo=SRVGREXCAS04.claranet.local) by staff00.mail.eu.clara.net (staff00.mail.eu.clara.net [80.168.65.68]:25) with esmtps (TLS-1.0:RSA_AES_128_CBC_SHA1:16) id 1RQk6r-0004eS-1J for idr@ietf.org (return-path ); Wed, 16 Nov 2011 18:21:21 +0000 Received: from SRVGREXMB03.claranet.local ([10.75.5.26]) by SRVGREXCAS04.claranet.local ([fe80::95c2:9976:e52:fe51%11]) with mapi id 14.01.0339.001; Wed, 16 Nov 2011 18:21:21 +0000 From: David Freedman To: "idr@ietf.org" Thread-Topic: Adoption of draft-varlashkin-bgp-nh-cost-02 as IDR WG document? Thread-Index: AQHMpIyKp2Fftr/D7kCwhsTsD4rY6g== Date: Wed, 16 Nov 2011 18:21:20 +0000 Message-ID: Accept-Language: en-GB, 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: [172.18.6.3] Content-Type: multipart/alternative; boundary="_000_CAE9AF9D67EB6davidfreedmaneuclaranet_" MIME-Version: 1.0 X-BorderScout-Spam: 0.00 X-BorderScout-Virus: clean Subject: Re: [Idr] Adoption of draft-varlashkin-bgp-nh-cost-02 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: Wed, 16 Nov 2011 18:21:24 -0000 --_000_CAE9AF9D67EB6davidfreedmaneuclaranet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >We have received a request from the authors to adopt draft-varlashkin-bgp-= nh-cost-02 as an IDR WG document. Support. David Freedman Claranet --_000_CAE9AF9D67EB6davidfreedmaneuclaranet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
>We have received a request from the authors to adopt dra= ft-varlashkin-bgp-nh-cost-02 as an IDR WG document.

Support.

David Freedman
Claranet

--_000_CAE9AF9D67EB6davidfreedmaneuclaranet_-- From rjs@rob.sh Wed Nov 16 10:23:54 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3634C11E8096 for ; Wed, 16 Nov 2011 10:23:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OM3pp0-RDz6r for ; Wed, 16 Nov 2011 10:23:53 -0800 (PST) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id B127111E808C for ; Wed, 16 Nov 2011 10:23:53 -0800 (PST) Received: from [93.97.180.64] (helo=latte.config) by cappuccino.rob.sh with esmtpa (Exim 4.69) (envelope-from ) id 1RQk7O-0004iB-9l; Wed, 16 Nov 2011 18:21:54 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Rob Shakir In-Reply-To: Date: Wed, 16 Nov 2011 18:23:49 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <826D5E21-3D31-4EC6-BFAE-885164D14ECB@rob.sh> References: To: David Freedman X-Mailer: Apple Mail (2.1084) Cc: "idr@ietf.org" Subject: Re: [Idr] Adoption of draft-varlashkin-bgp-nh-cost-02 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: Wed, 16 Nov 2011 18:23:54 -0000 On 16 Nov 2011, at 18:21, David Freedman wrote: >> We have received a request from the authors to adopt = draft-varlashkin-bgp-nh-cost-02 as an IDR WG document. >=20 > Support. +1. Thanks, r.= From keyupate@cisco.com Wed Nov 16 10:27:49 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1B4621F8E5F for ; Wed, 16 Nov 2011 10:27:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.25 X-Spam-Level: X-Spam-Status: No, score=-6.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZ-MGbs7fuIS for ; Wed, 16 Nov 2011 10:27:49 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 304A121F8B07 for ; Wed, 16 Nov 2011 10:27:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=keyupate@cisco.com; l=483; q=dns/txt; s=iport; t=1321468069; x=1322677669; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=0hgxDXwseiRsvCI3eLC16M9hU2jLoUmnA1m/uXqsc10=; b=G4l0M11DAuVVsNLPW231MYmxX+6zsBiArEGu1Pa0u4BZtbx6URhawia+ prehpTsc2TRGjBR0e4RZDXHv5pEYqzazuTOB4I7cKXLLppfs7hZZFQR78 /sGRZD8QA0YQ7ZNXeYKFlh3QeaNTyaaWnEgWBPJxNvXtI1PI2EIRyyndT 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EADkAxE6rRDoI/2dsb2JhbABDqgGBBYFyAQEBAwEBAQEPAScCATEQDQEIDl8wAQEEARIih2AImj0BnmQEihcEiBSMIIVEjFk X-IronPort-AV: E=Sophos;i="4.69,522,1315180800"; d="scan'208";a="14600342" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 16 Nov 2011 18:27:49 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pAGIRmgx027204; Wed, 16 Nov 2011 18:27:48 GMT Received: from xmb-sjc-239.amer.cisco.com ([128.107.191.105]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Nov 2011 10:27:48 -0800 Received: from 10.70.230.201 ([10.70.230.201]) by xmb-sjc-239.amer.cisco.com ([128.107.191.105]) via Exchange Front-End Server email.cisco.com ([64.104.123.70]) with Microsoft Exchange Server HTTP-DAV ; Wed, 16 Nov 2011 18:27:48 +0000 User-Agent: Microsoft-Entourage/12.31.0.110725 Date: Wed, 16 Nov 2011 10:27:46 -0800 From: Keyur Patel To: John Scudder , "idr@ietf.org List" Message-ID: Thread-Topic: [Idr] Adoption of draft-varlashkin-bgp-nh-cost-02 as IDR WG document? Thread-Index: AcykPwG7jl6Kwgf+R0CL/omsorSMmQATm4QH In-Reply-To: <7B61DC70-08D9-46C7-8C15-5DD339C61C2D@juniper.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 16 Nov 2011 18:27:48.0877 (UTC) FILETIME=[7184BBD0:01CCA48D] Subject: Re: [Idr] Adoption of draft-varlashkin-bgp-nh-cost-02 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: Wed, 16 Nov 2011 18:27:49 -0000 Support. -Keyur On 11/16/11 1:06 AM, "John Scudder" wrote: > Folks, > > We have received a request from the authors to adopt > draft-varlashkin-bgp-nh-cost-02 as an IDR WG document. Please send your > comments to the list. The deadline for comments is December 5, 2011 at noon > EST. > > Thanks, > > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From keyupate@cisco.com Wed Nov 16 10:42:49 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E430C21F8E61 for ; Wed, 16 Nov 2011 10:42:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.366 X-Spam-Level: X-Spam-Status: No, score=-6.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nvag1CQAjJLO for ; Wed, 16 Nov 2011 10:42:49 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA9C21F9518 for ; Wed, 16 Nov 2011 10:42:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=keyupate@cisco.com; l=499; q=dns/txt; s=iport; t=1321468964; x=1322678564; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=m9TAoWn35htCunNpAKTsXmBHibh9Et6w8rqs5Gm9zOg=; b=On0iY7zZAK0wAhegFxDL/r+hTykPjNEr/EDd6nHiKebKI1njxiG/p+en s7z3ytxCtTu3i6NVPJffFiHh9/Fmv6QnPyseMl3uql+frkglH8j9X7OlH ec31sZFJzncXLCs4xcS0m04o21d/jvpfqfN0v+v6p4jSSmZrBR/sVpQ0c M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAJcDxE6rRDoG/2dsb2JhbABDqgGBBYFyAQEBAwEBAQEPAScCATEQDQEIDl8wAQEEARIih2AImj0BnmUEihcEiBSMIIVEjFk X-IronPort-AV: E=Sophos;i="4.69,522,1315180800"; d="scan'208";a="14678629" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 16 Nov 2011 18:42:44 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAGIghlR005201; Wed, 16 Nov 2011 18:42:43 GMT Received: from xmb-sjc-239.amer.cisco.com ([128.107.191.105]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Nov 2011 10:42:43 -0800 Received: from 10.70.230.201 ([10.70.230.201]) by xmb-sjc-239.amer.cisco.com ([128.107.191.105]) via Exchange Front-End Server email.cisco.com ([64.104.123.70]) with Microsoft Exchange Server HTTP-DAV ; Wed, 16 Nov 2011 18:42:43 +0000 User-Agent: Microsoft-Entourage/12.31.0.110725 Date: Wed, 16 Nov 2011 10:42:41 -0800 From: Keyur Patel To: John Scudder , "idr@ietf.org List" Message-ID: Thread-Topic: [Idr] Adoption of draft-jasinska-ix-bgp-route-server-03 as IDR WG document? Thread-Index: AcykKh97kHpl4oYwTB6MrSZ7j/kTXgAZWXLU In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 16 Nov 2011 18:42:43.0776 (UTC) FILETIME=[86EB7C00:01CCA48F] Subject: Re: [Idr] Adoption of draft-jasinska-ix-bgp-route-server-03 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: Wed, 16 Nov 2011 18:42:50 -0000 Support. Regards, Keyur On 11/15/11 10:36 PM, "John Scudder" wrote: > Folks, > > We have received a request from the authors to adopt > draft-jasinska-ix-bgp-route-server-03 as an IDR WG document. Please send your > comments to the list. The deadline for comments is December 5, 2011 at noon > EST. > > Thanks, > > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From gdawra@cisco.com Wed Nov 16 10:54:48 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC07421F9436 for ; Wed, 16 Nov 2011 10:54:48 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc" X-Spam-Flag: NO X-Spam-Score: -6.366 X-Spam-Level: X-Spam-Status: No, score=-6.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6HSlpub0r2v for ; Wed, 16 Nov 2011 10:54:48 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id B52AD21F93B9 for ; Wed, 16 Nov 2011 10:54:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gdawra@cisco.com; l=1189; q=dns/txt; s=iport; t=1321469677; x=1322679277; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=SmOg2lI2PPa6gutvabaPn3xy+m5ECzOsnZzbLnF+POk=; b=fhi7hdqnQoGOgoZ9NINs6JJitOrxfDriBLmtLOtepTkJW3E3hE7Rw2/s GHkfnU+VhY4td4E1ZAl4ITNn2uj0YcVW0gB0lA4VcSMGT8kVv7Ab1XU4v /DTY7K3ahYFfsOJRbN5RpLIag2s+dJHqw7ALMUsWm0MQRByl8NcP6glVn Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsAAAAGxE6rRDoI/2dsb2JhbABDmXSNJIJqgQWBcgEBAQQBAQEPAScCATELDAYBCBEEAQEBJy4fCQgBAQQBDQUih2iaPQGeYgSKFwSIFIwghUSMVg X-IronPort-AV: E=Sophos;i="4.69,522,1315180800"; d="scan'208";a="14681356" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 16 Nov 2011 18:54:37 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pAGIsbdo008882; Wed, 16 Nov 2011 18:54:37 GMT Received: from xmb-sjc-238.amer.cisco.com ([128.107.191.16]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Nov 2011 10:54:37 -0800 Received: from 10.86.242.97 ([10.86.242.97]) by xmb-sjc-238.amer.cisco.com ([128.107.191.16]) via Exchange Front-End Server email.cisco.com ([144.254.231.95]) with Microsoft Exchange Server HTTP-DAV ; Wed, 16 Nov 2011 18:54:27 +0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Wed, 16 Nov 2011 13:54:17 -0500 From: Gaurav Dawra To: "UTTARO, JAMES" , "'Rob Shakir'" , John Scudder Message-ID: Thread-Topic: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document? Thread-Index: AcykPkoZv0rjpQtASsSyYlxRDSuk7AAWIQwAAAnPTaAACznYng== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 16 Nov 2011 18:54:37.0325 (UTC) FILETIME=[303A6BD0:01CCA491] Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 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: Wed, 16 Nov 2011 18:54:48 -0000 +1 Support Regards, -Gaurav Dawra On 11/16/11 9:54 AM, "UTTARO, JAMES" wrote: > +1 > > Jim Uttaro > > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Rob > Shakir > Sent: Wednesday, November 16, 2011 9:35 AM > To: John Scudder > Cc: idr@ietf.org List > Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document? > > > On 16 Nov 2011, at 09:01, John Scudder wrote: > >> Folks, >> >> We have received a request from the authors to adopt >> draft-l3vpn-legacy-rtc-00 as an IDR WG document. Please send your comments >> to the list. The deadline for comments is December 5, 2011 at noon EST. > > Hi John, IDR, > > I support adopting this draft as an IDR WG document. > > Kind regards, > r. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr -- Gaurav Dawra, Software Eng. gdawra@cisco.com .:|:.:|:. NSSTG CISCO From randy@psg.com Wed Nov 16 11:02:58 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA34E21F90C3 for ; Wed, 16 Nov 2011 11:02:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzMafR60L2Ak for ; Wed, 16 Nov 2011 11:02:58 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 96FD921F90C2 for ; Wed, 16 Nov 2011 11:02:58 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RQkl7-0009K7-L2; Wed, 16 Nov 2011 19:02:58 +0000 Date: Thu, 17 Nov 2011 03:02:56 +0800 Message-ID: From: Randy Bush To: John Scudder In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IETF IDR Subject: Re: [Idr] Adoption of draft-jasinska-ix-bgp-route-server-03 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: Wed, 16 Nov 2011 19:02:59 -0000 this seems quite reasonable randy From bvenkata@cisco.com Wed Nov 16 11:13:10 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6727411E808C for ; Wed, 16 Nov 2011 11:13:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NURRoPeXSCwb for ; Wed, 16 Nov 2011 11:13:09 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 0361C1F0C54 for ; Wed, 16 Nov 2011 11:13:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bvenkata@cisco.com; l=650; q=dns/txt; s=iport; t=1321470789; x=1322680389; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=gChDxzcRcD12rXT/3xKA9NmwtfgmxKfGnMbh3PVSZKY=; b=LNfMdLgOGEBqqNIho4mHsA7Vnx0D+Cf2iB7Ged1+Ug7xj0KbnvealLB/ nJuNlybm9/H7exHF+uaqrzFN8FxLAOY87kn9k0So0Wx/UnlPOUhInMzTC 61Y8K4idTzVDJdLJXzeUcjnod64FwLjc7DKy/r5MlAHu7UsIGkf6pe58q Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowAAHQKxE5Io8US/2dsb2JhbABDmXWQDoEFgXIBAQEEAQEBDwEdCjQXBAIBCA4DBAEBCwYXAQYBJh8JCAEBBAEKCAgah2iaPQGeZwSJNGMEiBKRZoxA X-IronPort-AV: E=Sophos;i="4.69,522,1315180800"; d="scan'208";a="3254119" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-4.cisco.com with ESMTP; 16 Nov 2011 19:13:03 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pAGJD3mX026628; Wed, 16 Nov 2011 19:13:03 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Nov 2011 00:43:03 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Nov 2011 00:43:01 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document? Thread-Index: AcykPkoZv0rjpQtASsSyYlxRDSuk7AAVW9pg References: From: "Balaji Pitta Venkatachalapathy (bvenkata)" To: "John Scudder" , X-OriginalArrivalTime: 16 Nov 2011 19:13:03.0095 (UTC) FILETIME=[C3518870:01CCA493] Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 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: Wed, 16 Nov 2011 19:13:10 -0000 Support!! Regards, Balaji -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of John Scudder Sent: Wednesday, November 16, 2011 1:01 AM To: idr@ietf.org List Subject: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document? Folks, We have received a request from the authors to adopt draft-l3vpn-legacy-rtc-00 as an IDR WG document. Please send your comments to the list. The deadline for comments is December 5, 2011 at noon EST. Thanks, --John _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From bashandy@cisco.com Wed Nov 16 11:19:25 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBBFB11E80E9 for ; Wed, 16 Nov 2011 11:19:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpwfwmgE-MVU for ; Wed, 16 Nov 2011 11:19:22 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id B83BE11E80C9 for ; Wed, 16 Nov 2011 11:19:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bashandy@cisco.com; l=1190; q=dns/txt; s=iport; t=1321471162; x=1322680762; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=xBrWNPcO1TG6M7GM7s+k9lQvgCMQrh/ZqXL3TnNo8HU=; b=CiddN2w1dvcNYHrb6DUcL7ujhkch9fv/yyJjrZYtvJlqAL0X85UtKjc4 Hj4rx4k1OD4SE4Z2iuape+DWt8EsEJ8thENUMm4llmPdk+QxwqOn0Wo/U 8gGn/AfGpM0CSbOhaJU0r4AXpRPu8yhkDisoG0x+FRJlE09+55Q47JUUQ 0=; X-Files: signature.asc : 251 X-IronPort-AV: E=Sophos;i="4.69,522,1315180800"; d="asc'?scan'208";a="14610761" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 16 Nov 2011 19:19:22 +0000 Received: from [128.107.163.79] (dhcp-128-107-163-79.cisco.com [128.107.163.79]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pAGJJMJg024098; Wed, 16 Nov 2011 19:19:22 GMT Message-ID: <4EC40CB9.2010007@cisco.com> Date: Wed, 16 Nov 2011 11:19:21 -0800 From: Ahmed Bashandy User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.24) Gecko/20111103 Thunderbird/3.1.16 MIME-Version: 1.0 To: John Scudder References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig853E406665486B49CE10485A" Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 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: Wed, 16 Nov 2011 19:19:25 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig853E406665486B49CE10485A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Support Thanks Ahmed Ahmed On 11/16/2011 1:01 AM, John Scudder wrote: > Folks, > > We have received a request from the authors to adopt draft-l3vpn-legacy= -rtc-00 as an IDR WG document. Please send your comments to the list. T= he deadline for comments is December 5, 2011 at noon EST. > > Thanks, > > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --------------enig853E406665486B49CE10485A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFOxAy6+G19kFA5zIYRArsEAJ4t4CM7PI2jBeVuwIxykvhGeD6uSACfcMe6 T5cEtXtfBb2FDdp2Pdr6zfg= =YAIi -----END PGP SIGNATURE----- --------------enig853E406665486B49CE10485A-- From asreekan@cisco.com Wed Nov 16 12:08:39 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA3FA1F0C45 for ; Wed, 16 Nov 2011 12:08:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+M71UjSTRD6 for ; Wed, 16 Nov 2011 12:08:39 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id E37E21F0C3C for ; Wed, 16 Nov 2011 12:08:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=asreekan@cisco.com; l=1948; q=dns/txt; s=iport; t=1321474116; x=1322683716; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=U09hdk6C43JC8XwgJ2aOA2RvOdITbBDjh/P+S50Gk0U=; b=ZIVjjAujURvq0qPxhiruC+C9oRQh9sZyj5jDdaS6MZ4GTXNXJhAabPPl PBX4/ulQjFrQQf6/l/NthR2RMcaVeZOEEUSW4uDb7VZyf0tlvKZ34dta0 hzDWSFru1MwFXZsG7JtTaF3dswPoZtGt4u+O7QMW9TqcDc3e7iPsSUlPK c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsAAJEXxE6rRDoH/2dsb2JhbABDmXWNJIJqgQWBcgEBAQQBAQEPAR0+CwwEAgEIEQQBAQEKBhcBBgEmHwkIAQEEARIIEweHaJo9AZ5oBIk0YwSHYzGRZIxZ X-IronPort-AV: E=Sophos;i="4.69,522,1315180800"; d="scan'208";a="14695899" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 16 Nov 2011 20:08:35 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pAGK8ZGT015430; Wed, 16 Nov 2011 20:08:35 GMT Received: from xmb-sjc-22b.amer.cisco.com ([128.107.191.112]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Nov 2011 12:08:35 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Nov 2011 12:08:34 -0800 Message-ID: <96327EF53EF71A48806DE2DFC034D57F0FF739C2@xmb-sjc-22b.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document? Thread-Index: Acykg9vqMf8xPSwHR7q/ey4rrPv+VAAE6Fig References: From: "Arjun Sreekantiah (asreekan)" To: "Pedro Marques" , "John Scudder" X-OriginalArrivalTime: 16 Nov 2011 20:08:35.0540 (UTC) FILETIME=[859C4940:01CCA49B] Cc: idr@ietf.org Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 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: Wed, 16 Nov 2011 20:08:40 -0000 Pedro, We have heard otherwise from many of our customers looking to deploy = RT-constrain. Upgrade of all legacy PEs to support RT-constrain is not = something that can be accomplished in a quick manner, this is mostly = done in a incremental fashion over a long period of time. A PE upgrade = can be a time consuming and elaborate process for many of the customers = and the below would provide a mechanism to derive benefits on = RT-constrain in the interim. I do not think the legacy PE solution is adding a great deal of = complexity. Yes, configuration steps are needed on the legacy PE to = specify RT membership information, we expect this can be automated = through the use of scripting tools to also specify legacy PE RTs when = provisioning the VPNs. Thanks Arjun -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of = Pedro Marques Sent: Wednesday, November 16, 2011 9:19 AM To: John Scudder Cc: idr@ietf.org List Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG = document? -1 I believe that the "legacy" is now the fact that rt-constraint is supported by the most common implementations. The proposed procedures for legacy PEs have a level of complexity that seems significantly higher than qualifying a new software release. Pedro. On Wed, Nov 16, 2011 at 1:01 AM, John Scudder wrote: > Folks, > > We have received a request from the authors to adopt = draft-l3vpn-legacy-rtc-00 as an IDR WG document. =A0Please send your = comments to the list. =A0The deadline for comments is December 5, 2011 = at noon EST. > > Thanks, > > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From pedro.r.marques@gmail.com Wed Nov 16 14:47:20 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D17EF21F91CC for ; Wed, 16 Nov 2011 14:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.97 X-Spam-Level: X-Spam-Status: No, score=-2.97 tagged_above=-999 required=5 tests=[AWL=0.629, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rH9dIKz7r2En for ; Wed, 16 Nov 2011 14:47:20 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 34D3821F916A for ; Wed, 16 Nov 2011 14:47:20 -0800 (PST) Received: by iaeo4 with SMTP id o4so1551811iae.31 for ; Wed, 16 Nov 2011 14:47:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=bwKyTNk8/9yzttJJkesFU/O3IQraeyLit5yE8EBCbGE=; b=gHhYwlkMPmW8HA3rHN1iZUkB74PKauzyTBYBP8xt6Lff0HJ/+enpty9oqwYxKk5xre qCefHEmjSo+kMRfM8JRSOmvGeoOUw/oxL/jC4gmRpThnCGKU5ARMAEbViX36xKqemopv UYrH+rG4N9PJZ2LTA3snbrhKfoJ+WkxuvZpEY= MIME-Version: 1.0 Received: by 10.231.3.194 with SMTP id 2mr563001ibo.68.1321483639598; Wed, 16 Nov 2011 14:47:19 -0800 (PST) Received: by 10.231.12.2 with HTTP; Wed, 16 Nov 2011 14:47:19 -0800 (PST) In-Reply-To: <96327EF53EF71A48806DE2DFC034D57F0FF739C2@xmb-sjc-22b.amer.cisco.com> References: <96327EF53EF71A48806DE2DFC034D57F0FF739C2@xmb-sjc-22b.amer.cisco.com> Date: Wed, 16 Nov 2011 14:47:19 -0800 Message-ID: From: Pedro Marques To: "Arjun Sreekantiah (asreekan)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: idr@ietf.org Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 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: Wed, 16 Nov 2011 22:47:20 -0000 Arjun, Do you believe that the provisioning system support necessary to support the PE functionality defined in this draft can be "accomplished in a quick manner" ? Software qualification and updates are indeed a very slow process. The only process i'm aware of that in practice tends to prove even slower is to develop new functionality in provisioning systems and change operational procedures in order to support something like what is proposed here. Thus my deep skepticism on the value of the WG adopting this as a work item. Pedro. On Wed, Nov 16, 2011 at 12:08 PM, Arjun Sreekantiah (asreekan) wrote: > Pedro, > We have heard otherwise from many of our customers looking to deploy RT-c= onstrain. =A0Upgrade of all legacy PEs to support RT-constrain is not somet= hing that can be accomplished in a quick manner, this is mostly done in a i= ncremental fashion over a long period of time. A PE upgrade can be a time c= onsuming and elaborate process for many of the customers and the below woul= d provide a mechanism to derive benefits on RT-constrain in the interim. > > I do not think the legacy PE solution is adding a great deal of complexit= y. Yes, configuration steps are needed on the legacy PE to specify RT membe= rship information, we expect this can be automated through the use of scrip= ting tools to also specify legacy PE RTs when provisioning the VPNs. > > Thanks > Arjun > > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Ped= ro Marques > Sent: Wednesday, November 16, 2011 9:19 AM > To: John Scudder > Cc: idr@ietf.org List > Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG docume= nt? > > -1 > > I believe that the "legacy" is now the fact that rt-constraint is > supported by the most common implementations. > > The proposed procedures for legacy PEs have a level of complexity that > seems significantly higher than qualifying a new software release. > > =A0Pedro. > > > On Wed, Nov 16, 2011 at 1:01 AM, John Scudder wrote: >> Folks, >> >> We have received a request from the authors to adopt draft-l3vpn-legacy-= rtc-00 as an IDR WG document. =A0Please send your comments to the list. =A0= The deadline for comments is December 5, 2011 at noon EST. >> >> Thanks, >> >> --John >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From robert@raszuk.net Wed Nov 16 15:01:31 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6DD11E8083 for ; Wed, 16 Nov 2011 15:01:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=0.632, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4+Ib-O-gbwuX for ; Wed, 16 Nov 2011 15:01:30 -0800 (PST) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id A6A1E11E807F for ; Wed, 16 Nov 2011 15:01:30 -0800 (PST) Received: (qmail 15456 invoked by uid 399); 16 Nov 2011 23:01:29 -0000 Received: from unknown (HELO ?10.0.1.3?) (130.129.67.115) by mail1310.opentransfer.com with ESMTP; 16 Nov 2011 23:01:29 -0000 X-Originating-IP: 130.129.67.115 Message-ID: <4EC440CA.9070904@raszuk.net> Date: Thu, 17 Nov 2011 00:01:30 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Rob Shakir References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 23:01:31 -0000 Hi Rob, While I may even agree with your points reg considerations for a software upgrade on the PEs - which in many cases may just not be available due to given's vendor software release strategy - I do not agree that this is so hard to enhance your provisioning system to update the rr-group command on the RR when you are adding/deleting/modifying a RT on the PE given RR is serving. And if you do that there is no need for inbound signalling like proposed in this draft. Rgs, R. > On 16 Nov 2011, at 17:19, Pedro Marques wrote: > >> -1 >> >> I believe that the "legacy" is now the fact that rt-constraint is >> supported by the most common implementations. >> >> The proposed procedures for legacy PEs have a level of complexity >> that seems significantly higher than qualifying a new software >> release. > > While this if of course a valid argument, I believe that there are > some operational constraints that make this untrue. > > In an ideal world, all deployed PEs would be running current > hardware, and with software trains under active development. > Unfortunately, this is not always the case - and hence the > requirement is more than a software qualification to support RTC. The > options here are migration to new hardware platforms, which comes > with significant operational costs, or put up with some operational > complexity to better utilise existing assets whilst allowing network > growth elsewhere, and delay expenditure. > > I realise that such non-technical requirements may fall outside of > the consideration of IETF working groups - but I feel strongly that > there is some trade-off to be made that sacrifices some absolute > correctness to provide technologies that allow operators to meet > their network's commercial requirements. > > We should (of course) consider the extent to which such compromises > compromise network robustness - but I can't say that I agree that > this draft upsets the complexity/benefit balance. I would be > interested to hear if you do. > > Kind regards, r. > > > _______________________________________________ Idr mailing list > Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr > > From robert@raszuk.net Wed Nov 16 16:13:47 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA5A91F0C46 for ; Wed, 16 Nov 2011 16:13:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=0.553, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNe9Jg7cQCBq for ; Wed, 16 Nov 2011 16:13:47 -0800 (PST) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 33E251F0C35 for ; Wed, 16 Nov 2011 16:13:47 -0800 (PST) Received: (qmail 26376 invoked by uid 399); 17 Nov 2011 00:13:46 -0000 Received: from unknown (HELO ?10.0.1.3?) (130.129.67.115) by mail1310.opentransfer.com with ESMTP; 17 Nov 2011 00:13:46 -0000 X-Originating-IP: 130.129.67.115 Message-ID: <4EC451BB.90103@raszuk.net> Date: Thu, 17 Nov 2011 01:13:47 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "idr@ietf.org List" References: <9B76DC1E-7F59-4E07-B90D-762A173B8C82@juniper.net> <4EC3883F.3060602@juniper.net> In-Reply-To: <4EC3883F.3060602@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Idr] Adoption of draft-zeng-idr-bgp-mtu-extension-01 as IDR WG document? 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, 17 Nov 2011 00:13:48 -0000 If I understand justification for this work it dates back to invention of "mpls mtu" command on routing operating system where for whatever reason when hosts can not detect the right MTU router performing MPLS imposition had to fragment IPv4 packets in order to fit bigger frames into smaller LSP pipes. If we just consider that reason while setting such MTU may be administratively easy in given domain the problem becomes harder across domains as you need to lift the old fashion telephone and ask Mr. Peer what is your min MTU of today. Moreover when such MTU changes Mr Peer must inform you or your users starts crying so you are calling him again. I see not much harm to automate such process and carry MTU value in BGP 3107. Other protocols have already been extended to perform MTU propagation - example RSVP: http://www.google.com/search?gcx=w&sourceid=chrome&ie=UTF-8&q=mpls-mtu-signaling-rsvp Said all of this I am much more in favor to detect MTU host to host in the data plane. And if this is broken for whatever reason we should focus on fixing that problem rather then patching it on routers. The latter while was/is possible for IPv4 (even when neglecting presence of DF bit) in the light of upcoming IPv6 which sort of does not allow network fragmentation may be a bit hard. Regards, R. > no support - IMO its not needed as a router could send the > PMTU/ICMP message in the downstream direction where a > LSP egress node decapsulates the packet and finally sends > it back to the ingress node; > we are doing this successfully for other labeled environments, > so i fail to see why LBGP is different in that respect. > > tx, > > /hannes > > On 11/16/2011 10:01 AM, John Scudder wrote: >> Folks, >> >> We have received a request from the authors to adopt >> ft-zeng-idr-bgp-mtu-extension-01 as an IDR WG document. Please send >> your comments to the list. The deadline for comments is December 5, >> 2011 at noon EST. >> >> Thanks, >> >> --John >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > From hannes@juniper.net Wed Nov 16 17:13:54 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2FAE1F0C4A for ; Wed, 16 Nov 2011 17:13:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYjztPc+zJ3Y for ; Wed, 16 Nov 2011 17:13:54 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id DACEA1F0C51 for ; Wed, 16 Nov 2011 17:13:53 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTsRf0RG7DwMCEoTy29QuaMoZR8BdKsC2@postini.com; Wed, 16 Nov 2011 17:13:53 PST Received: from klsh.jnpr.net (172.30.152.52) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 16 Nov 2011 17:12:41 -0800 Received: from localhost (localhost [127.0.0.1]) (uid 1550) by klsh.jnpr.net with local; Thu, 17 Nov 2011 02:12:39 +0100 id 0081A3B9.4EC45F87.00003292 Date: Thu, 17 Nov 2011 02:12:39 +0100 From: Hannes Gredler To: Robert Raszuk Message-ID: <20111117011239.GB12875@juniper.net> References: <9B76DC1E-7F59-4E07-B90D-762A173B8C82@juniper.net> <4EC3883F.3060602@juniper.net> <4EC451BB.90103@raszuk.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <4EC451BB.90103@raszuk.net> User-Agent: Mutt/1.5.11 Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-zeng-idr-bgp-mtu-extension-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, 17 Nov 2011 01:13:54 -0000 On Thu, Nov 17, 2011 at 01:13:47AM +0100, Robert Raszuk wrote: | If I understand justification for this work it dates back to invention | of "mpls mtu" command on routing operating system where for whatever | reason when hosts can not detect the right MTU router performing MPLS | imposition had to fragment IPv4 packets in order to fit bigger frames | into smaller LSP pipes. | | If we just consider that reason while setting such MTU may be | administratively easy in given domain the problem becomes harder across | domains as you need to lift the old fashion telephone and ask Mr. Peer | what is your min MTU of today. Moreover when such MTU changes Mr Peer | must inform you or your users starts crying so you are calling him again. wouldn't a more straightforward to make PMTU to work between end-systems and fix "whatever reason" ? | I see not much harm to automate such process and carry MTU value in BGP | 3107. the part that i do not understand is how an implementation shall compute the MTU of a core iBGP segment ? unless all of the underlying link MTU gets signaled in a protocol like LDP|IGP there is no way to "automate" that process; | Other protocols have already been extended to perform MTU | propagation - example RSVP: | | http://www.google.com/search?gcx=w&sourceid=chrome&ie=UTF-8&q=mpls-mtu-signaling-rsvp good example: i'd argue that the brief difference is that RSVP usually is deployed in a hop-by-hop fashion (and hence can implement a min(link-MTU) along the LSP and iBGP is not. | Said all of this I am much more in favor to detect MTU host to host in | the data plane. And if this is broken for whatever reason we should | focus on fixing that problem rather then patching it on routers. The | latter while was/is possible for IPv4 (even when neglecting presence of | DF bit) in the light of upcoming IPv6 which sort of does not allow | network fragmentation may be a bit hard. | | >no support - IMO its not needed as a router could send the | >PMTU/ICMP message in the downstream direction where a | >LSP egress node decapsulates the packet and finally sends | >it back to the ingress node; | >we are doing this successfully for other labeled environments, | >so i fail to see why LBGP is different in that respect. | > | >tx, | > | >/hannes | > | >On 11/16/2011 10:01 AM, John Scudder wrote: | >>Folks, | >> | >>We have received a request from the authors to adopt | >>ft-zeng-idr-bgp-mtu-extension-01 as an IDR WG document. Please send | >>your comments to the list. The deadline for comments is December 5, | >>2011 at noon EST. | >> | >>Thanks, | >> | >>--John | >>_______________________________________________ | >>Idr mailing list | >>Idr@ietf.org | >>https://www.ietf.org/mailman/listinfo/idr | >_______________________________________________ | >Idr mailing list | >Idr@ietf.org | >https://www.ietf.org/mailman/listinfo/idr | > | > | From hannes@juniper.net Wed Nov 16 17:17:15 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3D31F0C51 for ; Wed, 16 Nov 2011 17:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKTJD9IiAVoB for ; Wed, 16 Nov 2011 17:17:14 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3779C1F0C4A for ; Wed, 16 Nov 2011 17:17:14 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTsRglbiKHZfJS+kvI6IwfICWvweNc7Qd@postini.com; Wed, 16 Nov 2011 17:17:14 PST Received: from klsh.jnpr.net (172.30.152.52) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 16 Nov 2011 17:15:26 -0800 Received: from localhost (localhost [127.0.0.1]) (uid 1550) by klsh.jnpr.net with local; Thu, 17 Nov 2011 02:15:24 +0100 id 0081A3BE.4EC4602C.000032BC Date: Thu, 17 Nov 2011 02:15:24 +0100 From: Hannes Gredler To: Jie Dong Message-ID: <20111117011524.GC12875@juniper.net> References: <9B76DC1E-7F59-4E07-B90D-762A173B8C82@juniper.net> <4EC3883F.3060602@juniper.net> <76CD132C3ADEF848BD84D028D243C92722A19519@szxeml509-mbs.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <76CD132C3ADEF848BD84D028D243C92722A19519@szxeml509-mbs.china.huawei.com> User-Agent: Mutt/1.5.11 Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of ft-zeng-idr-bgp-mtu-extension-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, 17 Nov 2011 01:17:15 -0000 On Wed, Nov 16, 2011 at 01:40:32PM +0000, Jie Dong wrote: | Hi Hannes, | | Thanks for your comment. Could you help provide in which document is this solution specified? | | RFC1191(PMTU discovery) says: "It is expected that future routing protocols will be able to provide accurate PMTU information within a routing area..." And since as we know other label sigaling protocols have defined the control plane based MTU discovery, it would be reasonble to also have this mechanism for labeled bgp. can you elaborate how the MTU shall be computed for iBGP path which consists of a (more than one) set of links ? | Also for some inter-AS scenarios data plane MTU discovery mechanism may not be allowed. | | Regards, | Jie | ________________________________________ | From: idr-bounces@ietf.org [idr-bounces@ietf.org] on behalf of Hannes Gredler [hannes@juniper.net] | Sent: Wednesday, November 16, 2011 17:54 | To: John Scudder | Cc: idr@ietf.org List | Subject: Re: [Idr] Adoption of ft-zeng-idr-bgp-mtu-extension-01 as IDR WG document? | | no support - IMO its not needed as a router could send the | PMTU/ICMP message in the downstream direction where a | LSP egress node decapsulates the packet and finally sends | it back to the ingress node; | we are doing this successfully for other labeled environments, | so i fail to see why LBGP is different in that respect. | | tx, | | /hannes | | On 11/16/2011 10:01 AM, John Scudder wrote: | > Folks, | > | > We have received a request from the authors to adopt ft-zeng-idr-bgp-mtu-extension-01 as an IDR WG document. Please send your comments to the list. The deadline for comments is December 5, 2011 at noon EST. | > | > Thanks, | > | > --John | > _______________________________________________ | > Idr mailing list | > Idr@ietf.org | > https://www.ietf.org/mailman/listinfo/idr | _______________________________________________ | Idr mailing list | Idr@ietf.org | https://www.ietf.org/mailman/listinfo/idr From jeff.tantsura@ericsson.com Wed Nov 16 17:22:50 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6861F0C35 for ; Wed, 16 Nov 2011 17:22:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Qa6y-LFVQuZ for ; Wed, 16 Nov 2011 17:22:46 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC9B21F8BF0 for ; Wed, 16 Nov 2011 17:22:46 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pAH1MiJi030506; Wed, 16 Nov 2011 19:22:45 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.111]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 16 Nov 2011 20:22:38 -0500 From: Jeff Tantsura To: John Scudder Date: Wed, 16 Nov 2011 20:22:38 -0500 Thread-Topic: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document? Thread-Index: Acykx2St5Aw3MLI3RhKJW/5K085wfA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 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, 17 Nov 2011 01:22:50 -0000 Yes/support=20 Regards, Jeff On Nov 16, 2011, at 5:04 PM, "John Scudder" wrote: > Folks, >=20 > We have received a request from the authors to adopt draft-l3vpn-legacy-r= tc-00 as an IDR WG document. Please send your comments to the list. The d= eadline for comments is December 5, 2011 at noon EST. >=20 > Thanks, >=20 > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From robert@raszuk.net Wed Nov 16 17:28:36 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C50FF1F0C69 for ; Wed, 16 Nov 2011 17:28:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[AWL=0.491, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id doGjZyOUSUCH for ; Wed, 16 Nov 2011 17:28:31 -0800 (PST) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id B1BD21F0C68 for ; Wed, 16 Nov 2011 17:28:30 -0800 (PST) Received: (qmail 8292 invoked by uid 399); 17 Nov 2011 01:28:30 -0000 Received: from unknown (HELO ?130.129.19.9?) (130.129.19.9) by mail1310.opentransfer.com with ESMTP; 17 Nov 2011 01:28:30 -0000 X-Originating-IP: 130.129.19.9 Message-ID: <4EC4633E.9000608@raszuk.net> Date: Thu, 17 Nov 2011 02:28:30 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Hannes Gredler References: <9B76DC1E-7F59-4E07-B90D-762A173B8C82@juniper.net> <4EC3883F.3060602@juniper.net> <4EC451BB.90103@raszuk.net> <20111117011239.GB12875@juniper.net> In-Reply-To: <20111117011239.GB12875@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-zeng-idr-bgp-mtu-extension-01 as IDR WG document? 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, 17 Nov 2011 01:28:36 -0000 Hannes, > wouldn't a more straightforward to make PMTU to work between > end-systems and fix "whatever reason" ? Of course and that is why I said in my original mail: "Said all of this I am much more in favor to detect MTU host to host in the data plane. And if this is broken for whatever reason we should focus on fixing that problem rather then patching it on routers." > | Other protocols have already been extended to perform MTU > | propagation - example RSVP: > | > |http://www.google.com/search?gcx=w&sourceid=chrome&ie=UTF-8&q=mpls-mtu-signaling-rsvp > > good example: i'd argue that the brief difference is that RSVP usually is > deployed in a hop-by-hop fashion (and hence can implement a min(link-MTU) along the > LSP and iBGP is not. True. So if one would like to map such RSVP carried MTU on ASBRs into 3107 would you support it ? Just curious ... Cheers, R. From asreekan@cisco.com Wed Nov 16 18:04:48 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF9E21F87D9 for ; Wed, 16 Nov 2011 18:04:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJnmR6LyWg6k for ; Wed, 16 Nov 2011 18:04:47 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 9F15F21F8663 for ; Wed, 16 Nov 2011 18:04:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=asreekan@cisco.com; l=3444; q=dns/txt; s=iport; t=1321495487; x=1322705087; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=yqkEnHGGdnkW+nyfMNlAHrh/CKphQlS94RdipMPX2Lc=; b=MpwvPVE6g/MurIL9GuhQaAzrvvKo9v8AO7+ydYuwXoApbT+WoF/AhPl4 e0hHuCJb/o5zHvlahksL+iBHe1vg7KdSM7M5g6eoQVhlgJURjFT8q1gSR 34ZqX3QWR5UKHdUn43F1iaoBMsMXmGcqIc2UuSWWGMv07MYarpSTkuejs I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArQAANRqxE6rRDoH/2dsb2JhbABCmXiNJIJqgQWBcgEBAQQBAQEPAR0+CwwEAgEIEQQBAQEKBhcBBgEgBh8JCAEBBBMIEQIHh2iUeAGeYwSJNGMEh2MxkWSFB4dS X-IronPort-AV: E=Sophos;i="4.69,524,1315180800"; d="scan'208";a="14693050" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 17 Nov 2011 02:04:47 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pAH24laJ005665; Thu, 17 Nov 2011 02:04:47 GMT Received: from xmb-sjc-22b.amer.cisco.com ([128.107.191.112]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Nov 2011 18:04:47 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Nov 2011 18:04:45 -0800 Message-ID: <96327EF53EF71A48806DE2DFC034D57F0FF73B0D@xmb-sjc-22b.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document? Thread-Index: AcyksbNVhpTcj5EpS5+nuoPA2CZyNwAGTFyA References: <96327EF53EF71A48806DE2DFC034D57F0FF739C2@xmb-sjc-22b.amer.cisco.com> From: "Arjun Sreekantiah (asreekan)" To: "Pedro Marques" X-OriginalArrivalTime: 17 Nov 2011 02:04:47.0068 (UTC) FILETIME=[4808A9C0:01CCA4CD] Cc: idr@ietf.org Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 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, 17 Nov 2011 02:04:48 -0000 -----Original Message----- From: Pedro Marques [mailto:pedro.r.marques@gmail.com]=20 Sent: Wednesday, November 16, 2011 2:47 PM To: Arjun Sreekantiah (asreekan) Cc: John Scudder; idr@ietf.org Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG = document? >Arjun, >Do you believe that the provisioning system support necessary to >support the PE functionality defined in this draft can be >"accomplished in a quick manner" ? Pedro, I would believe this would be less intensive to develop than the = software qualification and upgrade. It would be good to give customers the choice to adopt either approach = in any event. What we see in SP deployments today is that the RR scale is increasing = rapidly and this solution will help prolong the life of legacy PE = hardware until they are ready for the upgrade, by reducing the scale of = routes the legacy PE deals with in its RR peering. Arjun Software qualification and updates are indeed a very slow process. The only process i'm aware of that in practice tends to prove even slower is to develop new functionality in provisioning systems and change operational procedures in order to support something like what is proposed here. Thus my deep skepticism on the value of the WG adopting this as a work item. Pedro. On Wed, Nov 16, 2011 at 12:08 PM, Arjun Sreekantiah (asreekan) wrote: > Pedro, > We have heard otherwise from many of our customers looking to deploy = RT-constrain. =A0Upgrade of all legacy PEs to support RT-constrain is = not something that can be accomplished in a quick manner, this is mostly = done in a incremental fashion over a long period of time. A PE upgrade = can be a time consuming and elaborate process for many of the customers = and the below would provide a mechanism to derive benefits on = RT-constrain in the interim. > > I do not think the legacy PE solution is adding a great deal of = complexity. Yes, configuration steps are needed on the legacy PE to = specify RT membership information, we expect this can be automated = through the use of scripting tools to also specify legacy PE RTs when = provisioning the VPNs. > > Thanks > Arjun > > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of = Pedro Marques > Sent: Wednesday, November 16, 2011 9:19 AM > To: John Scudder > Cc: idr@ietf.org List > Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG = document? > > -1 > > I believe that the "legacy" is now the fact that rt-constraint is > supported by the most common implementations. > > The proposed procedures for legacy PEs have a level of complexity that > seems significantly higher than qualifying a new software release. > > =A0Pedro. > > > On Wed, Nov 16, 2011 at 1:01 AM, John Scudder wrote: >> Folks, >> >> We have received a request from the authors to adopt = draft-l3vpn-legacy-rtc-00 as an IDR WG document. =A0Please send your = comments to the list. =A0The deadline for comments is December 5, 2011 = at noon EST. >> >> Thanks, >> >> --John >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From ju1738@att.com Wed Nov 16 18:14:34 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB351F0C88 for ; Wed, 16 Nov 2011 18:14:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[AWL=0.601, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2qRSha4DX1V for ; Wed, 16 Nov 2011 18:14:28 -0800 (PST) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id B6A851F0C53 for ; Wed, 16 Nov 2011 18:14:28 -0800 (PST) X-Env-Sender: ju1738@att.com X-Msg-Ref: server-13.tower-120.messagelabs.com!1321496066!49703919!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7205 invoked from network); 17 Nov 2011 02:14:27 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-13.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Nov 2011 02:14:27 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pAH2Espl018589; Wed, 16 Nov 2011 21:14:54 -0500 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (misout7msghub9c.itservices.sbc.com [144.151.223.82]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pAH2EnDe018541 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Nov 2011 21:14:49 -0500 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([169.254.1.53]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.01.0339.001; Wed, 16 Nov 2011 21:14:20 -0500 From: "UTTARO, JAMES" To: "'Pedro Marques'" , John Scudder Thread-Topic: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document? Thread-Index: AcykPkoZv0rjpQtASsSyYlxRDSuk7AAb3NAAAAadNUA= Date: Thu, 17 Nov 2011 02:14:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.97.178] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 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, 17 Nov 2011 02:14:34 -0000 Pedro, Testing, certifying and deploying a new release on a legacy platform is not= warranted for the benefit that traditional RT-Constrain brings. There is a= lso the fact that it has to be deployed on lots and lots of legacy PEs.. Th= ese legacy PEs also have to be able to support the demands of traditional R= T-Constrain. This level of complexity in in of itself is daunting. Beyond t= he fact that we have to ask vendors to provide a new release for a legacy p= latform there is also the reality that doing this takes cycles away from ne= w development we would like to do to support new features and services. RT-= Constrain as envisioned is a mechanism to create what is essentially multip= oint-multipoint multicast trees or better put a directed graph that contain= s leafs and nodes for a given VPN. This approach assumes that VPN distribut= ion is "localized" and attempts to reduce the resources needed for a given = BGP topology. In my experience this assumption has not proved to be correct= . That being said RT-Constrain is quite useful for reducing the amount of s= tate a leaf ( PE ) needs to process when a new VRF is added, soft refresh i= s performed or there is PE reboot. So what we need is a mechanism to solve = that problem without the overhead as detailed above.. Legacy RT provides a = simple mechanism to deploy a mechanism that protects the legacy PE from hav= ing to process large amounts of routing state.. It is also extensible and m= ay act as a traditional RT-Constrain leaf. So, without divulging our plans.. Hypothetically Legacy RT-Constrain can be= deployed in an incremental fashion using existing machinery on the legacy = PEs and a new release on the RRs. This is quite attractive..=20 So to address your comment directly it is much harder to certify/test/deplo= y a new release on possibly thousands of legacy PEs instead of 10s of RRs..= Configuration can be done in an incremental fashion for the problem we fac= e which is protecting legacy PEs. Thanks, Jim Uttaro =09 -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Pedro= Marques Sent: Wednesday, November 16, 2011 12:19 PM To: John Scudder Cc: idr@ietf.org List Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document= ? -1 I believe that the "legacy" is now the fact that rt-constraint is supported by the most common implementations. The proposed procedures for legacy PEs have a level of complexity that seems significantly higher than qualifying a new software release. Pedro. On Wed, Nov 16, 2011 at 1:01 AM, John Scudder wrote: > Folks, > > We have received a request from the authors to adopt draft-l3vpn-legacy-r= tc-00 as an IDR WG document. =A0Please send your comments to the list. =A0T= he deadline for comments is December 5, 2011 at noon EST. > > Thanks, > > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From asreekan@cisco.com Wed Nov 16 18:14:37 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25EB31F0C8C for ; Wed, 16 Nov 2011 18:14:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sw8fHSJkQ-K7 for ; Wed, 16 Nov 2011 18:14:36 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8264C1F0C8A for ; Wed, 16 Nov 2011 18:14:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=asreekan@cisco.com; l=3036; q=dns/txt; s=iport; t=1321496076; x=1322705676; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=MWsJ/TzKP91eyzZ0wU0h+r6pjWNcE9RtJzPAI9kB4Fk=; b=Tfh/JKHFJmF2vPdAoL39nbhIM1qf7QtWeQgALRSWArcFAIc+dO/mVb1v TilEiN7bR37WW9mb68da03Wx1XtSSYuAjPV50XNMqSfObEe3jIYaM+T3k OJt0rdi68fjQtrWyN6gU1vTpBiEcbm9rm3gkXz2/yKErxYLRq67/x0Ujf U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArQAABNtxE6rRDoJ/2dsb2JhbABCmXiNJIJqgQWBcgEBAQMBAQEBCwQBHQorCQsFBwQCAQgRBAEBAQoGFwEGASYfCQgBAQQBEggah2AIlHkBnl8EiTRjBIgUkWSMWQ X-IronPort-AV: E=Sophos;i="4.69,524,1315180800"; d="scan'208";a="14694416" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 17 Nov 2011 02:14:36 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pAH2EamZ028814; Thu, 17 Nov 2011 02:14:36 GMT Received: from xmb-sjc-22b.amer.cisco.com ([128.107.191.112]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Nov 2011 18:14:36 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Nov 2011 18:14:34 -0800 Message-ID: <96327EF53EF71A48806DE2DFC034D57F0FF73B13@xmb-sjc-22b.amer.cisco.com> In-Reply-To: <4EC440CA.9070904@raszuk.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document? Thread-Index: Acyks7Jqyx43ugrNTF2bubrYSVpkfwAGfjBw References: <4EC440CA.9070904@raszuk.net> From: "Arjun Sreekantiah (asreekan)" To: , "Rob Shakir" X-OriginalArrivalTime: 17 Nov 2011 02:14:36.0154 (UTC) FILETIME=[A7280DA0:01CCA4CE] Cc: idr@ietf.org Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 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, 17 Nov 2011 02:14:37 -0000 -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: Wednesday, November 16, 2011 3:02 PM To: Rob Shakir Cc: idr@ietf.org List Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document? >Hi Rob, >While I may even agree with your points reg considerations for a=20 >software upgrade on the PEs - which in many cases may just not be=20 >available due to given's vendor software release strategy - I do not=20 >agree that this is so hard to enhance your provisioning system to update=20 >the rr-group command on the RR when you are adding/deleting/modifying a >RT on the PE given RR is serving. >And if you do that there is no need for inbound signalling like proposed=20 >in this draft. Robert, This would mean that every time you have to update the RT configuration on the PE, you would also have to update corresponding RT list (rr-group) config on all RRs the PE is peering with. Thus the RT configuration change in no longer restricted to the PE alone and would not scale very well as the number of PEs on which you need to make the change increases. Thanks Arjun > On 16 Nov 2011, at 17:19, Pedro Marques wrote: > >> -1 >> >> I believe that the "legacy" is now the fact that rt-constraint is >> supported by the most common implementations. >> >> The proposed procedures for legacy PEs have a level of complexity >> that seems significantly higher than qualifying a new software >> release. > > While this if of course a valid argument, I believe that there are > some operational constraints that make this untrue. > > In an ideal world, all deployed PEs would be running current > hardware, and with software trains under active development. > Unfortunately, this is not always the case - and hence the > requirement is more than a software qualification to support RTC. The > options here are migration to new hardware platforms, which comes > with significant operational costs, or put up with some operational > complexity to better utilise existing assets whilst allowing network > growth elsewhere, and delay expenditure. > > I realise that such non-technical requirements may fall outside of > the consideration of IETF working groups - but I feel strongly that > there is some trade-off to be made that sacrifices some absolute > correctness to provide technologies that allow operators to meet > their network's commercial requirements. > > We should (of course) consider the extent to which such compromises > compromise network robustness - but I can't say that I agree that > this draft upsets the complexity/benefit balance. I would be > interested to hear if you do. > > Kind regards, r. > > > _______________________________________________ Idr mailing list > Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From hannes@juniper.net Wed Nov 16 18:22:05 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1F11F0C94 for ; Wed, 16 Nov 2011 18:22:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMu3eK3bVZFi for ; Wed, 16 Nov 2011 18:22:04 -0800 (PST) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 2946F1F0C54 for ; Wed, 16 Nov 2011 18:22:04 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKTsRvy52Eqt8Rqzd81sevfAkfudDC0pln@postini.com; Wed, 16 Nov 2011 18:22:04 PST Received: from klsh.jnpr.net (172.30.152.52) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 16 Nov 2011 18:18:24 -0800 Received: from localhost (localhost [127.0.0.1]) (uid 1550) by klsh.jnpr.net with local; Thu, 17 Nov 2011 03:18:22 +0100 id 0081A225.4EC46EEE.0000344B Date: Thu, 17 Nov 2011 03:18:22 +0100 From: Hannes Gredler To: Robert Raszuk Message-ID: <20111117021821.GA13347@juniper.net> References: <9B76DC1E-7F59-4E07-B90D-762A173B8C82@juniper.net> <4EC3883F.3060602@juniper.net> <4EC451BB.90103@raszuk.net> <20111117011239.GB12875@juniper.net> <4EC4633E.9000608@raszuk.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <4EC4633E.9000608@raszuk.net> User-Agent: Mutt/1.5.11 Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-zeng-idr-bgp-mtu-extension-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, 17 Nov 2011 02:22:05 -0000 On Thu, Nov 17, 2011 at 02:28:30AM +0100, Robert Raszuk wrote: | Hannes, | | >wouldn't a more straightforward to make PMTU to work between | >end-systems and fix "whatever reason" ? | | Of course and that is why I said in my original mail: | | "Said all of this I am much more in favor to detect MTU host to host in | the data plane. And if this is broken for whatever reason we should | focus on fixing that problem rather then patching it on routers." | | >| Other protocols have already been extended to perform MTU | >| propagation - example RSVP: | >| | >|http://www.google.com/search?gcx=w&sourceid=chrome&ie=UTF-8&q=mpls-mtu-signaling-rsvp | > | >good example: i'd argue that the brief difference is that RSVP usually is | >deployed in a hop-by-hop fashion (and hence can implement a min(link-MTU) | >along the | >LSP and iBGP is not. | | True. So if one would like to map such RSVP carried MTU on ASBRs into | 3107 would you support it ? Just curious ... for RSVP this would be doable, however ... i am worried about the complexities and scaling implications surrounding this. as per your example everytime a iBGP 3107 path resolves over a RSVP i need to callback into BGP, check if there is a MTU change of the resolved path, and if so, re-build all outgoing BGP messages. From robert@raszuk.net Wed Nov 16 18:23:55 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01EAF1F0CA6 for ; Wed, 16 Nov 2011 18:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJ32ZvpUqprx for ; Wed, 16 Nov 2011 18:23:50 -0800 (PST) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE7E1F0C54 for ; Wed, 16 Nov 2011 18:23:50 -0800 (PST) Received: (qmail 4755 invoked by uid 399); 17 Nov 2011 02:23:49 -0000 Received: from unknown (HELO ?130.129.19.9?) (130.129.19.9) by mail1310.opentransfer.com with ESMTP; 17 Nov 2011 02:23:49 -0000 X-Originating-IP: 130.129.19.9 Message-ID: <4EC47036.603@raszuk.net> Date: Thu, 17 Nov 2011 03:23:50 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Arjun Sreekantiah (asreekan)" References: <4EC440CA.9070904@raszuk.net> <96327EF53EF71A48806DE2DFC034D57F0FF73B13@xmb-sjc-22b.amer.cisco.com> In-Reply-To: <96327EF53EF71A48806DE2DFC034D57F0FF73B13@xmb-sjc-22b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document? 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, 17 Nov 2011 02:23:55 -0000 Hi Arjun, > Robert, > > This would mean that every time you have to update the RT configuration > on the PE, you would also have to update corresponding RT list > (rr-group) config on all RRs the PE is peering with. Yes- on all two RRs in 99 % of VPNv4/v6 deployments. > Thus the RT > configuration change in no longer restricted to the PE alone and would > not scale very well as the number of PEs on which you need to make the > change increases. I do not know what does not scale. In a decent network size provisioning is automated anyway so operator would have a RT modification template then just perform single modification to RT anyway. And it is just the template which would need to be one time enhanced to accommodate such additional RT insertion on the peering RRs given PE is a client of. I do not know why this would be difficult. Best regards, R. From ju1738@att.com Wed Nov 16 18:41:20 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0DCE11E80A3 for ; Wed, 16 Nov 2011 18:41:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tE9fTnzwaUvF for ; Wed, 16 Nov 2011 18:41:20 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 19A3211E809A for ; Wed, 16 Nov 2011 18:41:20 -0800 (PST) X-Env-Sender: ju1738@att.com X-Msg-Ref: server-14.tower-119.messagelabs.com!1321497678!1456728!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26203 invoked from network); 17 Nov 2011 02:41:18 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-14.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Nov 2011 02:41:18 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pAH2fjP8005704; Wed, 16 Nov 2011 21:41:46 -0500 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pAH2fcBT005588 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Nov 2011 21:41:38 -0500 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([169.254.1.53]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.01.0339.001; Wed, 16 Nov 2011 21:41:10 -0500 From: "UTTARO, JAMES" To: "'Arjun Sreekantiah (asreekan)'" , "robert@raszuk.net" , Rob Shakir Thread-Topic: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document? Thread-Index: AcykPkoZv0rjpQtASsSyYlxRDSuk7AAb3NAAAAIl2gAACdBWAAAGvicAAAmXU7A= Date: Thu, 17 Nov 2011 02:41:09 +0000 Message-ID: References: <4EC440CA.9070904@raszuk.net> <96327EF53EF71A48806DE2DFC034D57F0FF73B13@xmb-sjc-22b.amer.cisco.com> In-Reply-To: <96327EF53EF71A48806DE2DFC034D57F0FF73B13@xmb-sjc-22b.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.97.178] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 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, 17 Nov 2011 02:41:21 -0000 Coupling customer provisioning and management of BGP infrastructure ( RRs )= is not workable is a large scale network.=20 Jim Uttaro -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Arjun= Sreekantiah (asreekan) Sent: Wednesday, November 16, 2011 9:15 PM To: robert@raszuk.net; Rob Shakir Cc: idr@ietf.org Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document= ? -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: Wednesday, November 16, 2011 3:02 PM To: Rob Shakir Cc: idr@ietf.org List Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document? >Hi Rob, >While I may even agree with your points reg considerations for a=20 >software upgrade on the PEs - which in many cases may just not be=20 >available due to given's vendor software release strategy - I do not=20 >agree that this is so hard to enhance your provisioning system to update=20 >the rr-group command on the RR when you are adding/deleting/modifying a >RT on the PE given RR is serving. >And if you do that there is no need for inbound signalling like proposed=20 >in this draft. Robert, This would mean that every time you have to update the RT configuration on the PE, you would also have to update corresponding RT list (rr-group) config on all RRs the PE is peering with. Thus the RT configuration change in no longer restricted to the PE alone and would not scale very well as the number of PEs on which you need to make the change increases. Thanks Arjun > On 16 Nov 2011, at 17:19, Pedro Marques wrote: > >> -1 >> >> I believe that the "legacy" is now the fact that rt-constraint is >> supported by the most common implementations. >> >> The proposed procedures for legacy PEs have a level of complexity >> that seems significantly higher than qualifying a new software >> release. > > While this if of course a valid argument, I believe that there are > some operational constraints that make this untrue. > > In an ideal world, all deployed PEs would be running current > hardware, and with software trains under active development. > Unfortunately, this is not always the case - and hence the > requirement is more than a software qualification to support RTC. The > options here are migration to new hardware platforms, which comes > with significant operational costs, or put up with some operational > complexity to better utilise existing assets whilst allowing network > growth elsewhere, and delay expenditure. > > I realise that such non-technical requirements may fall outside of > the consideration of IETF working groups - but I feel strongly that > there is some trade-off to be made that sacrifices some absolute > correctness to provide technologies that allow operators to meet > their network's commercial requirements. > > We should (of course) consider the extent to which such compromises > compromise network robustness - but I can't say that I agree that > this draft upsets the complexity/benefit balance. I would be > interested to hear if you do. > > Kind regards, r. > > > _______________________________________________ Idr mailing list > Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From robert@raszuk.net Wed Nov 16 18:41:58 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92C4F1F0C7C for ; Wed, 16 Nov 2011 18:41:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.259 X-Spam-Level: X-Spam-Status: No, score=-2.259 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdDZgMoKdafr for ; Wed, 16 Nov 2011 18:41:58 -0800 (PST) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id D19531F0C53 for ; Wed, 16 Nov 2011 18:41:57 -0800 (PST) Received: (qmail 14967 invoked by uid 399); 17 Nov 2011 02:41:57 -0000 Received: from unknown (HELO ?130.129.19.9?) (130.129.19.9) by mail1310.opentransfer.com with ESMTP; 17 Nov 2011 02:41:57 -0000 X-Originating-IP: 130.129.19.9 Message-ID: <4EC47476.8000708@raszuk.net> Date: Thu, 17 Nov 2011 03:41:58 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Hannes Gredler , "idr@ietf.org List" References: <9B76DC1E-7F59-4E07-B90D-762A173B8C82@juniper.net> <4EC3883F.3060602@juniper.net> <4EC451BB.90103@raszuk.net> <20111117011239.GB12875@juniper.net> <4EC4633E.9000608@raszuk.net> <20111117021821.GA13347@juniper.net> In-Reply-To: <20111117021821.GA13347@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Idr] Adoption of draft-zeng-idr-bgp-mtu-extension-01 as IDR WG document? 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, 17 Nov 2011 02:41:58 -0000 Hi Hannes, > | True. So if one would like to map such RSVP carried MTU on ASBRs into > | 3107 would you support it ? Just curious ... > > for RSVP this would be doable, however ... > i am worried about the complexities and scaling implications > surrounding this. as per your example everytime a iBGP 3107 path > resolves over a RSVP i need to callback into BGP, check if there > is a MTU change of the resolved path, and if so, re-build all > outgoing BGP messages. True too. Since we are at this topic I think there is number of issues which needs to be discussed a bit more before we reach any conclusions not maybe on this particular draft, but on the problem space. Few open questions .. - Does MTU discovery belong in control plane or data plane or both ? - Is http://tools.ietf.org/html/rfc2923 complete reg TCP MTU issues ? How about other protocols ? Can those be always solved by data plane ? - Is MTU problem affecting only MPLS networks or also pure IP networks ? - If protocols have been enhanced to simplify MTU discovery intra-domian should some effort be spend to also address inter-domain cases ? Regards, R. From robert@raszuk.net Wed Nov 16 18:47:19 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17AC11F0C54 for ; Wed, 16 Nov 2011 18:47:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QiFGCXVzARrA for ; Wed, 16 Nov 2011 18:47:18 -0800 (PST) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 53BC521F8E88 for ; Wed, 16 Nov 2011 18:47:18 -0800 (PST) Received: (qmail 19166 invoked by uid 399); 17 Nov 2011 02:47:17 -0000 Received: from unknown (HELO ?130.129.19.9?) (130.129.19.9) by mail1310.opentransfer.com with ESMTP; 17 Nov 2011 02:47:17 -0000 X-Originating-IP: 130.129.19.9 Message-ID: <4EC475B5.8010009@raszuk.net> Date: Thu, 17 Nov 2011 03:47:17 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "UTTARO, JAMES" References: <4EC440CA.9070904@raszuk.net> <96327EF53EF71A48806DE2DFC034D57F0FF73B13@xmb-sjc-22b.amer.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org" Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document? 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, 17 Nov 2011 02:47:19 -0000 I respectfully disagree. It all depends how one builds and uses network management tools in any size of the network. If in some cases such management tools are not effective perhaps it would be a good idea to fix them rather then propose implementation hacks and protocol extensions to work around them. Best regards, R. > Coupling customer provisioning and management of BGP infrastructure ( > RRs ) is not workable is a large scale network. > > Jim Uttaro From jie.dong@huawei.com Wed Nov 16 18:53:38 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 287B11F0C99 for ; Wed, 16 Nov 2011 18:53:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.475 X-Spam-Level: X-Spam-Status: No, score=-6.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id roI+fVD6p11f for ; Wed, 16 Nov 2011 18:53:37 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 63EF11F0C54 for ; Wed, 16 Nov 2011 18:53:37 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUS00BNUAIG2O@szxga04-in.huawei.com> for idr@ietf.org; Thu, 17 Nov 2011 10:49:28 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUS00MF2AIGSK@szxga04-in.huawei.com> for idr@ietf.org; Thu, 17 Nov 2011 10:49:28 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFC40178; Thu, 17 Nov 2011 10:49:28 +0800 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 17 Nov 2011 10:49:22 +0800 Received: from SZXEML509-MBS.china.huawei.com ([169.254.2.220]) by szxeml403-hub.china.huawei.com ([10.82.67.35]) with mapi id 14.01.0323.003; Thu, 17 Nov 2011 10:42:30 +0800 Date: Thu, 17 Nov 2011 02:42:29 +0000 From: Jie Dong In-reply-to: <20111117021821.GA13347@juniper.net> X-Originating-IP: [172.24.2.40] To: Hannes Gredler , Robert Raszuk Message-id: <76CD132C3ADEF848BD84D028D243C92722A199C5@szxeml509-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [Idr] Adoption of draft-zeng-idr-bgp-mtu-extension-01 as IDR WG document? Thread-index: AQHMpNBQY4IMtYHPSkCG5nlrgBq6A5WwWZKC X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <9B76DC1E-7F59-4E07-B90D-762A173B8C82@juniper.net> <4EC3883F.3060602@juniper.net> <4EC451BB.90103@raszuk.net> <20111117011239.GB12875@juniper.net> <4EC4633E.9000608@raszuk.net> <20111117021821.GA13347@juniper.net> Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-zeng-idr-bgp-mtu-extension-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, 17 Nov 2011 02:53:38 -0000 ________________________________________ | >| Other protocols have already been extended to perform MTU | >| propagation - example RSVP: | >| | >|http://www.google.com/search?gcx=w&sourceid=chrome&ie=UTF-8&q=mpls-mtu-signaling-rsvp | > | >good example: i'd argue that the brief difference is that RSVP usually is | >deployed in a hop-by-hop fashion (and hence can implement a min(link-MTU) | >along the | >LSP and iBGP is not. | | True. So if one would like to map such RSVP carried MTU on ASBRs into | 3107 would you support it ? Just curious ... for RSVP this would be doable, however ... i am worried about the complexities and scaling implications surrounding this. as per your example everytime a iBGP 3107 path resolves over a RSVP i need to callback into BGP, check if there is a MTU change of the resolved path, and if so, re-build all outgoing BGP messages. #Jie: Good catch. Section 3.4 of this draft describes considerations on possible route flapping. And the re-advertisement of BGP update would only happen if the Path MTU decreases, since this may impact the service traffic. For MTU increase scenario, the update would be hold down until some other changes require a bgp re-advertisement. And LDP also has the control plane MTU discovery mechanism: http://tools.ietf.org/html/rfc3988 Thanks, Jie _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From hannes@juniper.net Wed Nov 16 19:04:15 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3B5F11E80B4 for ; Wed, 16 Nov 2011 19:04:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KOCJei05U7q for ; Wed, 16 Nov 2011 19:04:15 -0800 (PST) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5B311E80B0 for ; Wed, 16 Nov 2011 19:04:13 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTsR5lkWs/0SD7aZ+eePu9SsbIkmJZHJT@postini.com; Wed, 16 Nov 2011 19:04:14 PST Received: from [172.23.3.231] (172.23.3.231) by smtp.juniper.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 16 Nov 2011 19:00:14 -0800 Message-ID: <4EC47961.80304@juniper.net> Date: Thu, 17 Nov 2011 04:02:57 +0100 From: Hannes Gredler User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: References: <9B76DC1E-7F59-4E07-B90D-762A173B8C82@juniper.net> <4EC3883F.3060602@juniper.net> <4EC451BB.90103@raszuk.net> <20111117011239.GB12875@juniper.net> <4EC4633E.9000608@raszuk.net> <20111117021821.GA13347@juniper.net> <4EC47476.8000708@raszuk.net> In-Reply-To: <4EC47476.8000708@raszuk.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-zeng-idr-bgp-mtu-extension-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, 17 Nov 2011 03:04:16 -0000 On 11/17/2011 3:41 AM, Robert Raszuk wrote: > Hi Hannes, > >> | True. So if one would like to map such RSVP carried MTU on ASBRs into >> | 3107 would you support it ? Just curious ... >> >> for RSVP this would be doable, however ... >> i am worried about the complexities and scaling implications >> surrounding this. as per your example everytime a iBGP 3107 path >> resolves over a RSVP i need to callback into BGP, check if there >> is a MTU change of the resolved path, and if so, re-build all >> outgoing BGP messages. > > True too. Since we are at this topic I think there is number of issues > which needs to be discussed a bit more before we reach any conclusions > not maybe on this particular draft, but on the problem space. > Few open questions .. > > - Does MTU discovery belong in control plane or data plane or both ? i feel that this really should belong into the dataplane. for IP we have PMTU and for MPLS paths we could do a similar thing using lsping. > - Is http://tools.ietf.org/html/rfc2923 complete reg TCP MTU issues ? > How about other protocols ? Can those be always solved by data plane ? can you give some specific example for "other protocols" ? > - Is MTU problem affecting only MPLS networks or also pure IP networks ? both and - it depends if the endpoint can actually play an active role and hence perform path MTU discovery. > - If protocols have been enhanced to simplify MTU discovery intra-domian > should some effort be spend to also address inter-domain cases ? using lsping we have got support for both interdomain and intradomain protocols. From jie.dong@huawei.com Wed Nov 16 19:31:49 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 591BA1F0C98 for ; Wed, 16 Nov 2011 19:31:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.493 X-Spam-Level: X-Spam-Status: No, score=-6.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhTDnvo+ak58 for ; Wed, 16 Nov 2011 19:31:48 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 904C91F0CC5 for ; Wed, 16 Nov 2011 19:31:48 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUS005KECG8UB@szxga05-in.huawei.com> for idr@ietf.org; Thu, 17 Nov 2011 11:31:20 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUS002ITCFTAX@szxga05-in.huawei.com> for idr@ietf.org; Thu, 17 Nov 2011 11:31:20 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFA89250; Thu, 17 Nov 2011 11:31:19 +0800 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 17 Nov 2011 11:31:12 +0800 Received: from SZXEML509-MBS.china.huawei.com ([169.254.2.220]) by szxeml402-hub.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0323.003; Thu, 17 Nov 2011 11:31:11 +0800 Date: Thu, 17 Nov 2011 03:31:10 +0000 From: Jie Dong In-reply-to: <4EC47476.8000708@raszuk.net> X-Originating-IP: [172.24.2.40] To: "robert@raszuk.net" , Hannes Gredler , "idr@ietf.org List" Message-id: <76CD132C3ADEF848BD84D028D243C92722A19AC0@szxeml509-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [Idr] Adoption of draft-zeng-idr-bgp-mtu-extension-01 as IDR WG document? Thread-index: AQHMpNMnVQ3ymtyRM0qxsEPca9FJNZWwZJSu X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <9B76DC1E-7F59-4E07-B90D-762A173B8C82@juniper.net> <4EC3883F.3060602@juniper.net> <4EC451BB.90103@raszuk.net> <20111117011239.GB12875@juniper.net> <4EC4633E.9000608@raszuk.net> <20111117021821.GA13347@juniper.net> <4EC47476.8000708@raszuk.net> Subject: Re: [Idr] Adoption of draft-zeng-idr-bgp-mtu-extension-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, 17 Nov 2011 03:31:49 -0000 Hi, > for RSVP this would be doable, however ... > i am worried about the complexities and scaling implications > surrounding this. as per your example everytime a iBGP 3107 path > resolves over a RSVP i need to callback into BGP, check if there > is a MTU change of the resolved path, and if so, re-build all > outgoing BGP messages. True too. Since we are at this topic I think there is number of issues which needs to be discussed a bit more before we reach any conclusions not maybe on this particular draft, but on the problem space. #Jie: As in my previous reply to Hannes, The update would only be signaled when the MTU decreases, this is necessary as otherwise this would impact the service traffic. Few open questions .. - Does MTU discovery belong in control plane or data plane or both ? #Jie: I think we already have both. And they would be used in different cases. Data plane MTU discovery needs be run periodically to catch the changes of MTU, or it could be performed when some packets are already getting discarded. Control plane MTU discovery could discover the MTU change proactively, and the re-signaling is only needed when the MTU decrease. - Is http://tools.ietf.org/html/rfc2923 complete reg TCP MTU issues ? How about other protocols ? Can those be always solved by data plane ? #Jie: I guess you mean other "transport protocol". Here one way is to define and perform specific procedures for each transport protocol, and another way is to discover the MTU in lower layer and provide this to each transport protocols. - Is MTU problem affecting only MPLS networks or also pure IP networks ? #Jie: Both IMO. - If protocols have been enhanced to simplify MTU discovery intra-domian should some effort be spend to also address inter-domain cases ? #Jie: Sounds reasonable to me. Regards, Jie _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From internet-drafts@ietf.org Wed Nov 16 23:20:15 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA9C1F0CD3; Wed, 16 Nov 2011 23:20:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GyAbVi2mhZI; Wed, 16 Nov 2011 23:20:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7268F1F0CBE; Wed, 16 Nov 2011 23:20:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64 Message-ID: <20111117072014.26174.53963.idtracker@ietfa.amsl.com> Date: Wed, 16 Nov 2011 23:20:14 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-error-handling-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, 17 Nov 2011 07:20:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of= the IETF. Title : Revised Error Handling for BGP UPDATE Messages Author(s) : John G. Scudder Enke Chen Pradosh Mohapatra Keyur Patel Filename : draft-ietf-idr-error-handling-00.txt Pages : 10 Date : 2011-11-16 According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable as a session reset would impact not only routes with the offending attribute, but also other valid routes exchanged over the session. This document partially revises the error handling for UPDATE messages, and provides guidelines for the authors of documents defining new attributes. Finally, it revises the error handling procedures for several existing attributes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-error-handling-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-error-handling-00.txt From jakob.heitz@ericsson.com Thu Nov 17 00:50:06 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D8121F9A6B for ; Thu, 17 Nov 2011 00:50:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.07 X-Spam-Level: X-Spam-Status: No, score=-6.07 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WoaUEn-fm7o for ; Thu, 17 Nov 2011 00:50:05 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 94D4921F9A73 for ; Thu, 17 Nov 2011 00:50:05 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id pAH8o4No018944 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Nov 2011 02:50:05 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.111]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 17 Nov 2011 03:50:04 -0500 From: Jakob Heitz To: John Scudder Date: Thu, 17 Nov 2011 03:50:46 -0500 Thread-Topic: [Idr] Adoption of ft-zeng-idr-bgp-mtu-extension-01 as IDR WG document? Thread-Index: AcylBeYKcE/Mnr+aQX2iOnghUeMhdg== Message-ID: References: <9B76DC1E-7F59-4E07-B90D-762A173B8C82@juniper.net> In-Reply-To: <9B76DC1E-7F59-4E07-B90D-762A173B8C82@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of ft-zeng-idr-bgp-mtu-extension-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, 17 Nov 2011 08:50:06 -0000 support. For L3VPN option c, BGP contributes one link of an end-to-end LSP. This dra= ft proposes a good way to propagate the PMTU across that link. One part I don't understand is in 3.3.c, why does the speaker not pass alon= g the MTU from the previous link? In the L3VPN option c, 3 label case, it s= ets itself as nexthop. It should preserve the MTU, I think. In some cases, such as a multihop BGP session, or a BGP session between loo= pback interfaces, it can not determine an MTU. This is of no concern. BGP w= ould simply not generate this MTU community. As for data plane/control plane arguments, I think a control protocol that = participates in the establishment of a tunnel is the best place to pass any= needed properties of that tunnel, including the MTU. Signaling of properti= es, including MTU belongs in the control plane. That after all is control. = The data plane is named "data", because that's all that belongs in it. -- Jakob Heitz. On Nov 16, 2011, at 1:04 AM, "John Scudder" wrote: > Folks, >=20 > We have received a request from the authors to adopt ft-zeng-idr-bgp-mtu-= extension-01 as an IDR WG document. Please send your comments to the list.= The deadline for comments is December 5, 2011 at noon EST. >=20 > Thanks, >=20 > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From bhavani@cisco.com Thu Nov 17 00:53:32 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C6321F9A90 for ; Thu, 17 Nov 2011 00:53:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qX3dvsvOx+P0 for ; Thu, 17 Nov 2011 00:53:31 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD6621F9A8F for ; Thu, 17 Nov 2011 00:53:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bhavani@cisco.com; l=450; q=dns/txt; s=iport; t=1321520011; x=1322729611; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=xa0JdP6c4CdlLLv23qdrLvmrnss0h0mIjGePvVtJohY=; b=XcnETjfTSa2QjzQL9JoIob10blgBMH6AJmb+JDsUPNHTn+96SAi1zbaf vgX7TWn2uG6u8i7hdXXJjXcYpz9KJ7ZPc4JxZOnGisdPLi9cysTTdLxq5 szm1wp+C9yyZlvQUA4mzTyFEaxaaOpLfUAl06y5dsM3V+eAmDeKTROf2t 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAbLxE6rRDoI/2dsb2JhbABCqX+BBYFyAQEBBAEBAQ8BJTYKEQsYCRYPCQMCAQIBFTATBgIBAR6HaJUOAZ41BIcCgxUEiBWMIIU7jGI X-IronPort-AV: E=Sophos;i="4.69,525,1315180800"; d="scan'208";a="14722569" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 17 Nov 2011 08:53:31 +0000 Received: from [10.21.166.124] ([10.21.166.124]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pAH8rVJW013747 for ; Thu, 17 Nov 2011 08:53:31 GMT Message-ID: <4EC4CB8A.5000509@cisco.com> Date: Thu, 17 Nov 2011 00:53:30 -0800 From: Bhavani Parise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: idr@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 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, 17 Nov 2011 08:53:32 -0000 support. -Bhavani On 11/16/2011 1:01 AM, John Scudder wrote: > Folks, > > We have received a request from the authors to adopt draft-l3vpn-legacy-rtc-00 as an IDR WG document. Please send your comments to the list. The deadline for comments is December 5, 2011 at noon EST. > > Thanks, > > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From bhavani@cisco.com Thu Nov 17 00:56:36 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DEBC21F9A9D for ; Thu, 17 Nov 2011 00:56:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbMdDNzZBPI2 for ; Thu, 17 Nov 2011 00:56:35 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 83FF321F9A98 for ; Thu, 17 Nov 2011 00:56:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bhavani@cisco.com; l=455; q=dns/txt; s=iport; t=1321520195; x=1322729795; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=tNskq7Q8F1eNLb/74PwUgobQP9ocPMlfo7LnU16hT+8=; b=gaafRrKT8c1MazlHBb+OvGj3m/W4F+/owB5yGbRDgu0W0VmVPrwk4+Xd F0ZS/TNG7SMa8/zeOiz1Ph9XIaXMJVG1mPNuGlKgnVvTJ3eERJR5Hgf7n PJKNKqIh8/boyx1OW0M0Y1VEI53tWR/ZqsWsOhPO0xvdyL7DlZru0E/Do s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABnMxE6rRDoJ/2dsb2JhbABCqX+BBYFyAQEBBAEBAQ8BJTYKEQsYCRYPCQMCAQIBFTATBgIBAR6HaJUSAZ41BIcCgxUEiBWMIIU7jGI X-IronPort-AV: E=Sophos;i="4.69,525,1315180800"; d="scan'208";a="14801538" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 17 Nov 2011 08:56:35 +0000 Received: from [10.21.166.124] ([10.21.166.124]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pAH8uYJ4025756 for ; Thu, 17 Nov 2011 08:56:35 GMT Message-ID: <4EC4CC42.5080901@cisco.com> Date: Thu, 17 Nov 2011 00:56:34 -0800 From: Bhavani Parise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: idr@ietf.org References: <7B61DC70-08D9-46C7-8C15-5DD339C61C2D@juniper.net> In-Reply-To: <7B61DC70-08D9-46C7-8C15-5DD339C61C2D@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Idr] Adoption of draft-varlashkin-bgp-nh-cost-02 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, 17 Nov 2011 08:56:36 -0000 support -Bhavani On 11/16/2011 1:06 AM, John Scudder wrote: > Folks, > > We have received a request from the authors to adopt draft-varlashkin-bgp-nh-cost-02 as an IDR WG document. Please send your comments to the list. The deadline for comments is December 5, 2011 at noon EST. > > Thanks, > > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From rajiva@cisco.com Thu Nov 17 01:11:45 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1867B21F9B3D for ; Thu, 17 Nov 2011 01:11:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKcXOrSQhVvs for ; Thu, 17 Nov 2011 01:11:44 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 4BDFF21F9B23 for ; Thu, 17 Nov 2011 01:11:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=967; q=dns/txt; s=iport; t=1321521104; x=1322730704; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=mVmdVkK8wuBB1S0bVCgKC7ed3VwlM+uRP1tMzo1VSg0=; b=D/f7NUVoUIXRc1WiZkW/BI1wQ1souKYrtMP0lyA+VWO3x7BKBS59l5M9 Uo9b0wq8R6eOfvyWrea4OhtOmFNZK4mCLYsi3LeA3ypNjndKvLMLPCzXn tuwYZLvC1g7jp0RzPnhBA/RUGiv4SDA2Pbsc0ERBNkorq2ZUGVsw8sBy7 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AooAACDPxE6tJXHB/2dsb2JhbABCmXiQB4EFgXIBAQEEAQEBDwEdCjQXBAIBCBEEAQEBCgYXAQYBJh8JCAEBBAESCBqHaJUbAZ41BIk0YwSIFZFkjFc X-IronPort-AV: E=Sophos;i="4.69,525,1315180800"; d="scan'208";a="36832573" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 17 Nov 2011 09:11:44 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id pAH9Bhnn023167 for ; Thu, 17 Nov 2011 09:11:43 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Nov 2011 03:11:43 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Nov 2011 03:11:41 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C068A7C24@XMB-RCD-111.cisco.com> In-Reply-To: <4EC4CC42.5080901@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Adoption of draft-varlashkin-bgp-nh-cost-02 as IDR WGdocument? Thread-Index: AcylBtOrZc66P0I5Q2+73YlE72FZYwAAhY5A References: <7B61DC70-08D9-46C7-8C15-5DD339C61C2D@juniper.net> <4EC4CC42.5080901@cisco.com> From: "Rajiv Asati (rajiva)" To: "Bhavani Parise (bhavani)" , X-OriginalArrivalTime: 17 Nov 2011 09:11:43.0763 (UTC) FILETIME=[ECC61E30:01CCA508] Subject: Re: [Idr] Adoption of draft-varlashkin-bgp-nh-cost-02 as IDR WGdocument? 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, 17 Nov 2011 09:11:45 -0000 Support. Cheers, Rajiv > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Bhavani > Parise (bhavani) > Sent: Thursday, November 17, 2011 3:57 AM > To: idr@ietf.org > Subject: Re: [Idr] Adoption of draft-varlashkin-bgp-nh-cost-02 as IDR > WGdocument? >=20 >=20 > support >=20 > -Bhavani >=20 > On 11/16/2011 1:06 AM, John Scudder wrote: > > Folks, > > > > We have received a request from the authors to adopt draft-varlashkin-bgp- > nh-cost-02 as an IDR WG document. Please send your comments to the list. The > deadline for comments is December 5, 2011 at noon EST. > > > > Thanks, > > > > --John > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > > >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From jie.dong@huawei.com Thu Nov 17 01:24:59 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CAB221F9B64 for ; Thu, 17 Nov 2011 01:24:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.206 X-Spam-Level: X-Spam-Status: No, score=-6.206 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dCz04z1gfuP for ; Thu, 17 Nov 2011 01:24:58 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE4321F9B56 for ; Thu, 17 Nov 2011 01:24:58 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUS007V8SRP86@szxga03-in.huawei.com> for idr@ietf.org; Thu, 17 Nov 2011 17:23:49 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUS002X1SRCQU@szxga03-in.huawei.com> for idr@ietf.org; Thu, 17 Nov 2011 17:23:49 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFD29346; Thu, 17 Nov 2011 17:23:49 +0800 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 17 Nov 2011 17:23:41 +0800 Received: from SZXEML509-MBS.china.huawei.com ([169.254.2.220]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.003; Thu, 17 Nov 2011 17:23:37 +0800 Date: Thu, 17 Nov 2011 09:23:36 +0000 From: Jie Dong In-reply-to: X-Originating-IP: [172.24.2.40] To: Jakob Heitz , John Scudder Message-id: <76CD132C3ADEF848BD84D028D243C92722A19E88@szxeml509-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [Idr] Adoption of ft-zeng-idr-bgp-mtu-extension-01 as IDR WG document? Thread-index: AQHMpQaG/LHSTeSL3kOHSJtjueDxWZWwx/tT X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <9B76DC1E-7F59-4E07-B90D-762A173B8C82@juniper.net> Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of ft-zeng-idr-bgp-mtu-extension-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, 17 Nov 2011 09:24:59 -0000 Hi Jakob, Thanks for your comments, and please see replies inline with #Jie. ________________________________________ From: idr-bounces@ietf.org [idr-bounces@ietf.org] on behalf of Jakob Heitz [jakob.heitz@ericsson.com] Sent: Thursday, November 17, 2011 16:50 To: John Scudder Cc: idr@ietf.org List Subject: Re: [Idr] Adoption of ft-zeng-idr-bgp-mtu-extension-01 as IDR WG document? support. For L3VPN option c, BGP contributes one link of an end-to-end LSP. This draft proposes a good way to propagate the PMTU across that link. One part I don't understand is in 3.3.c, why does the speaker not pass along the MTU from the previous link? In the L3VPN option c, 3 label case, it sets itself as nexthop. It should preserve the MTU, I think. #Jie: When the speaker sets itself as nexthop, this means it would be on the forwarding path of the LSP, and in this case it should compare the received LSP path MTU and "its BGP LSR Link MTU to its nexthop minus 4", and choose the smaller one as its LSP Path MTU, and then propagate this MTU to its upstream BGP peers. In some cases, such as a multihop BGP session, or a BGP session between loopback interfaces, it can not determine an MTU. This is of no concern. BGP would simply not generate this MTU community. #Jie: In this case BGP could choose the minimum of the link MTU between the two BGP speaker as its BGP LSR link MTU. As for data plane/control plane arguments, I think a control protocol that participates in the establishment of a tunnel is the best place to pass any needed properties of that tunnel, including the MTU. Signaling of properties, including MTU belongs in the control plane. That after all is control. The data plane is named "data", because that's all that belongs in it. #Jie: Agreed. Path MTU can be considered as a attribute of the LSP path and is reasonable to be advertised using the control plane. And we have done this in other label signaling protocols. Regards, Jie -- Jakob Heitz. On Nov 16, 2011, at 1:04 AM, "John Scudder" wrote: > Folks, > > We have received a request from the authors to adopt ft-zeng-idr-bgp-mtu-extension-01 as an IDR WG document. Please send your comments to the list. The deadline for comments is December 5, 2011 at noon EST. > > Thanks, > > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From jakob.heitz@ericsson.com Thu Nov 17 01:41:57 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 446F921F9B22 for ; Thu, 17 Nov 2011 01:41:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.067 X-Spam-Level: X-Spam-Status: No, score=-6.067 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YAokn+B5MW3 for ; Thu, 17 Nov 2011 01:41:56 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9869121F9B23 for ; Thu, 17 Nov 2011 01:41:56 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id pAH9fo8a019922 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Nov 2011 03:41:53 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.111]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 17 Nov 2011 04:41:50 -0500 From: Jakob Heitz To: Jie Dong Date: Thu, 17 Nov 2011 04:42:37 -0500 Thread-Topic: [Idr] Adoption of ft-zeng-idr-bgp-mtu-extension-01 as IDR WG document? Thread-Index: AcylDSEBOXRGiAmnRNS49OJD3rtrcQ== Message-ID: <648DB734-E419-4AC5-B904-25C4FAC5E4CF@ericsson.com> References: <9B76DC1E-7F59-4E07-B90D-762A173B8C82@juniper.net> <76CD132C3ADEF848BD84D028D243C92722A19E88@szxeml509-mbs.china.huawei.com> In-Reply-To: <76CD132C3ADEF848BD84D028D243C92722A19E88@szxeml509-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of ft-zeng-idr-bgp-mtu-extension-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, 17 Nov 2011 09:41:57 -0000 agreed, I must have misread your draft. -- Jakob Heitz. On Nov 17, 2011, at 1:23 AM, "Jie Dong" wrote: > Hi Jakob,=20 >=20 > Thanks for your comments, and please see replies inline with #Jie. >=20 > ________________________________________ > From: idr-bounces@ietf.org [idr-bounces@ietf.org] on behalf of Jakob Heit= z [jakob.heitz@ericsson.com] > Sent: Thursday, November 17, 2011 16:50 > To: John Scudder > Cc: idr@ietf.org List > Subject: Re: [Idr] Adoption of ft-zeng-idr-bgp-mtu-extension-01 as IDR W= G document? >=20 > support. >=20 > For L3VPN option c, BGP contributes one link of an end-to-end LSP. This d= raft proposes a good way to propagate the PMTU across that link. >=20 > One part I don't understand is in 3.3.c, why does the speaker not pass al= ong the MTU from the previous link? In the L3VPN option c, 3 label case, it= sets itself as nexthop. It should preserve the MTU, I think. >=20 > #Jie: When the speaker sets itself as nexthop, this means it would be on = the forwarding path of the LSP, and in this case it should compare the rece= ived LSP path MTU and "its BGP LSR Link MTU to its nexthop minus 4", and ch= oose the smaller one as its LSP Path MTU, and then propagate this MTU to it= s upstream BGP peers. >=20 > In some cases, such as a multihop BGP session, or a BGP session between l= oopback interfaces, it can not determine an MTU. This is of no concern. BGP= would simply not generate this MTU community. >=20 > #Jie: In this case BGP could choose the minimum of the link MTU between t= he two BGP speaker as its BGP LSR link MTU. >=20 >=20 > As for data plane/control plane arguments, I think a control protocol tha= t participates in the establishment of a tunnel is the best place to pass a= ny needed properties of that tunnel, including the MTU. Signaling of proper= ties, including MTU belongs in the control plane. That after all is control= . The data plane is named "data", because that's all that belongs in it. >=20 > #Jie: Agreed. Path MTU can be considered as a attribute of the LSP path a= nd is reasonable to be advertised using the control plane. And we have done= this in other label signaling protocols. >=20 > Regards, > Jie >=20 >=20 >=20 > -- > Jakob Heitz. >=20 >=20 > On Nov 16, 2011, at 1:04 AM, "John Scudder" wrote: >=20 >> Folks, >>=20 >> We have received a request from the authors to adopt ft-zeng-idr-bgp-mtu= -extension-01 as an IDR WG document. Please send your comments to the list= . The deadline for comments is December 5, 2011 at noon EST. >>=20 >> Thanks, >>=20 >> --John >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From jeff.tantsura@ericsson.com Thu Nov 17 01:51:22 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90ED221F9B37 for ; Thu, 17 Nov 2011 01:51:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9I8KvwaBN2gt for ; Thu, 17 Nov 2011 01:51:22 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0CDEE21F9B20 for ; Thu, 17 Nov 2011 01:51:22 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pAH9pKRj015127; Thu, 17 Nov 2011 03:51:21 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.111]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 17 Nov 2011 04:51:15 -0500 From: Jeff Tantsura To: John Scudder Date: Thu, 17 Nov 2011 04:51:28 -0500 Thread-Topic: [Idr] Adoption of draft-varlashkin-bgp-nh-cost-02 as IDR WG document? Thread-Index: AcylDnH9DgWa/aVKQP25r0xfj8rYQw== Message-ID: <8ED84DC6-DB22-4446-8004-DAB2366AAE86@ericsson.com> References: <7B61DC70-08D9-46C7-8C15-5DD339C61C2D@juniper.net> In-Reply-To: <7B61DC70-08D9-46C7-8C15-5DD339C61C2D@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-varlashkin-bgp-nh-cost-02 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, 17 Nov 2011 09:51:22 -0000 Yes/support Regards, Jeff On Nov 16, 2011, at 5:12 PM, "John Scudder" wrote: > Folks, >=20 > We have received a request from the authors to adopt draft-varlashkin-bgp= -nh-cost-02 as an IDR WG document. Please send your comments to the list. = The deadline for comments is December 5, 2011 at noon EST. >=20 > Thanks, >=20 > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From stephane.litkowski@orange.com Thu Nov 17 06:56:36 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA0221F9A38 for ; Thu, 17 Nov 2011 06:56:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTNLmUlsSjCG for ; Thu, 17 Nov 2011 06:56:32 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 7BBE121F9A20 for ; Thu, 17 Nov 2011 06:56:32 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 71D9726486D; Thu, 17 Nov 2011 15:56:31 +0100 (CET) Received: from puexcc41.nanterre.francetelecom.fr (unknown [10.168.74.60]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 5798635C045; Thu, 17 Nov 2011 15:56:31 +0100 (CET) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.46]) by puexcc41.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Nov 2011 15:56:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Nov 2011 15:56:30 +0100 Message-ID: <10837_1321541791_4EC5209F_10837_9783_1_4FC3556A36EE3646A09DAA60429F5335074DF3B7@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document? Thread-Index: Acykg9yqvrLEu4A+SmC2jSkKlQI+swAtJLxg References: From: To: "Pedro Marques" , "John Scudder" X-OriginalArrivalTime: 17 Nov 2011 14:56:30.0398 (UTC) FILETIME=[16F81DE0:01CCA539] X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.11.17.131516 Cc: idr@ietf.org Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 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, 17 Nov 2011 14:56:37 -0000 Pedro, Yes most recent code support it (only Juniper support it since years ;) ), = but some legacy platforms deployed in SP networks can't run these new codes= (and will never), IMHO there is a need for these PEs until decommissioning. Moreover modifying provisionning tool to add few lines may not be a big dea= l. Stephane -----Message d'origine----- De : idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] De la part de Pedro= Marques Envoy=E9 : mercredi 16 novembre 2011 18:19 =C0 : John Scudder Cc : idr@ietf.org List Objet : Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document? -1 I believe that the "legacy" is now the fact that rt-constraint is supported= by the most common implementations. The proposed procedures for legacy PEs have a level of complexity that seem= s significantly higher than qualifying a new software release. Pedro. On Wed, Nov 16, 2011 at 1:01 AM, John Scudder wrote: > Folks, > > We have received a request from the authors to adopt draft-l3vpn-legacy-r= tc-00 as an IDR WG document. =A0Please send your comments to the list. =A0T= he deadline for comments is December 5, 2011 at noon EST. > > Thanks, > > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration,=20 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;=20 they should not be distributed, used or copied without authorization. If you have received this email in error, please notify the sender and dele= te this message and its attachments.=20 As emails may be altered, France Telecom - Orange shall not be liable if th= is message was modified, changed or falsified. Thank you. From luis.tomotaki@verizon.com Thu Nov 17 16:43:09 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06EA71F0C92 for ; Thu, 17 Nov 2011 16:43:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.669 X-Spam-Level: X-Spam-Status: No, score=-2.669 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0deaOsbfXpQ for ; Thu, 17 Nov 2011 16:43:08 -0800 (PST) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) by ietfa.amsl.com (Postfix) with ESMTP id 00D541F0C84 for ; Thu, 17 Nov 2011 16:43:07 -0800 (PST) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by fldsmtpe02.verizon.com with ESMTP; 18 Nov 2011 00:43:06 +0000 From: "Tomotaki, Luis M." X-IronPort-AV: E=Sophos;i="4.69,530,1315180800"; d="scan'208,217";a="182151831" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi02.verizon.com with ESMTP; 18 Nov 2011 00:43:06 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([169.254.1.197]) by FHDP1LUMXC7HB04.us.one.verizon.com ([166.68.59.191]) with mapi; Thu, 17 Nov 2011 19:43:06 -0500 To: "idr@ietf.org" Date: Thu, 17 Nov 2011 19:43:04 -0500 Thread-Topic: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document? Thread-Index: Acyliwgt+WWZ3/omS+6Vrem07RcJUQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CF0505E12603CF4D8DA13F2325112A22AE7E966BFHDP1LUMXC7V31u_" MIME-Version: 1.0 Subject: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 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: Fri, 18 Nov 2011 00:45:38 -0000 --_000_CF0505E12603CF4D8DA13F2325112A22AE7E966BFHDP1LUMXC7V31u_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes/Support My comments coming from a large service provider regarding the adoption of = draft-l3vpn-legacy-rtc-00 as IDR WG document are the following: - We need support for the legacy PE draft since a large number of PEs in ma= ny service provider networks will never be able to support RFC 4684 since t= he code upgrade of these legacy PEs is not an option due to multiple reason= s such as end-of-life scenarios or costly hardware upgrades. - As a representative of a large service provider, our comment is that our = provisioning systems are highly automated and should easily be able to make= the provisioning changes needed to specify RT membership information on th= e legacy PEs during the VRF configuration with no additional risk to our cu= stomer traffic. - The VPNV4/VPNV6 RRs in our network are considered core infrastructure dev= ices that should NOT be exposed to daily provisioning activity that the man= ual addition of filters to the core RR would require. Luis Tomotaki Verizon PIP Senior Engineer - Network Planning On Nov 16, 2011, at 5:04 PM, "John Scudder" wrote: > Folks, > > We have received a request from the authors to adopt draft-l3vpn-legacy-r= tc-00 as an IDR WG document. Please send your comments to the list. The d= eadline for comments is December 5, 2011 at noon EST. > > Thanks, > > --John > _______________________________________________ > Idr mailing list > Idr at ietf.org > https://www.ietf.org/mailman/listinfo/idr --_000_CF0505E12603CF4D8DA13F2325112A22AE7E966BFHDP1LUMXC7V31u_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Yes/Support
 
My commen= ts coming=20 from a large service provider regarding the adoption of=20 draft-l3vpn-legacy-rtc-00 as IDR WG document are the following:
 <= /DIV>
-=20 We need support for the legacy PE draft since a large number of PEs in many= =20 service provider networks will never be able to support RFC 4684 since the = code=20 upgrade of these legacy PEs is not an option due to multiple reasons s= uch=20 as end-of-life scenarios or costly hardware upgrades.   =20
-=20 As a representative of a large service provider, our comment is that=20 our provisioning systems are h= ighly=20 automated and should easily be able to make the provisioning=20 changes needed to specify RT membership information on the legacy PEs= =20 during the VRF configuration with no additional risk to our customer=20 traffic. 
- The VPNV4/VPNV6 RRs in our net= work are considered core infrastructure devices that should NOT=20 be exposed to daily provisioning activity&n= bsp;that the manual addition of filters to the core RR would require. =20
 =
Luis Tomotaki
Verizon PIP
Senior Engineer - Network=20 Planning
 
 
On Nov 16, 2011, a= t 5:04=20 PM, "John Scudder" <jgs at juniper.net> wrote:

> Folks,
= >=20
> We have received a request from the authors to adopt=20 draft-l3vpn-legacy-rtc-00 as an IDR WG document.  Please send your com= ments=20 to the list.  The deadline for comments is December 5, 2011 at noon=20 EST.
>
> Thanks,
>
> --John
>=20 _______________________________________________
> Idr mailing list>=20 Idr at ietf.org
> https://www.ietf.org/mailman/listinfo/idr
--_000_CF0505E12603CF4D8DA13F2325112A22AE7E966BFHDP1LUMXC7V31u_-- From robert@raszuk.net Thu Nov 17 17:07:03 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 885E81F0C55 for ; Thu, 17 Nov 2011 17:07:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.323 X-Spam-Level: X-Spam-Status: No, score=-2.323 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooUPiF8G8Ni4 for ; Thu, 17 Nov 2011 17:07:03 -0800 (PST) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id CB0C51F0C34 for ; Thu, 17 Nov 2011 17:07:02 -0800 (PST) Received: (qmail 23049 invoked by uid 399); 18 Nov 2011 01:06:59 -0000 Received: from unknown (HELO ?10.0.1.3?) (130.129.67.115) by mail1310.opentransfer.com with ESMTP; 18 Nov 2011 01:06:59 -0000 X-Originating-IP: 130.129.67.115 Message-ID: <4EC5AFB4.70804@raszuk.net> Date: Fri, 18 Nov 2011 02:07:00 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Tomotaki, Luis M." References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org" Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 01:07:03 -0000 Luis, > - We need support for the legacy PE draft since a large number of PEs > in many service provider networks will never be able to support RFC > 4684 since the code upgrade of these legacy PEs is not an option due > to multiple reasons such as end-of-life scenarios or costly hardware > upgrades. Putting legacy RTC topic aside which is at the end of the day just an optimization it seems that your legacy PEs will also never be able to be upgraded with any other new functionality you or IETF may be coming with. Therefor you will not be able to run any new services on those PEs. And this is all because vendor XYZ decided to abandon the software development on a branch your and "many service providers" are using in production. That seems to me like much bigger issue that effectively this is your PE vendor to get to decide what services you are to offer on your PEs. > - As a representative of a large service provider, our > comment is that our provisioning systems are highly automated and > should easily be able to make the provisioning changes needed to > specify RT membership information on the legacy PEs during the VRF > configuration with no additional risk to our customer traffic. - The > VPNV4/VPNV6 RRs in our network are considered core infrastructure > devices that should NOT be exposed to daily provisioning activity > that the manual addition of filters to the core RR would require. If the provisioning is "highly automated" I fail to see why provisioning in "core infrastructure" would have to be a manual process. Best, R. From jakob.heitz@ericsson.com Thu Nov 17 18:42:55 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB17A1F0C5E for ; Thu, 17 Nov 2011 18:42:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.381 X-Spam-Level: X-Spam-Status: No, score=-6.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDmZjfCAr93n for ; Thu, 17 Nov 2011 18:42:54 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id D0CF41F0C34 for ; Thu, 17 Nov 2011 18:42:54 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pAI2gqZd017971; Thu, 17 Nov 2011 20:42:54 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.111]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Thu, 17 Nov 2011 21:42:51 -0500 From: Jakob Heitz To: Jeff Tantsura Date: Thu, 17 Nov 2011 21:43:40 -0500 Thread-Topic: [Idr] Adoption of draft-varlashkin-bgp-nh-cost-02 as IDR WG document? Thread-Index: Acylm8OelPsjycovT5e5h7Jd46d/DA== Message-ID: <03D73343-7F1A-4FB7-B29B-FA4B84DB33C8@ericsson.com> References: <7B61DC70-08D9-46C7-8C15-5DD339C61C2D@juniper.net> <8ED84DC6-DB22-4446-8004-DAB2366AAE86@ericsson.com> In-Reply-To: <8ED84DC6-DB22-4446-8004-DAB2366AAE86@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-varlashkin-bgp-nh-cost-02 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: Fri, 18 Nov 2011 02:42:55 -0000 Support -- Jakob Heitz. On Nov 17, 2011, at 1:51 AM, "Jeff Tantsura" w= rote: > Yes/support >=20 > Regards, > Jeff >=20 > On Nov 16, 2011, at 5:12 PM, "John Scudder" wrote: >=20 >> Folks, >>=20 >> We have received a request from the authors to adopt draft-varlashkin-bg= p-nh-cost-02 as an IDR WG document. Please send your comments to the list.= The deadline for comments is December 5, 2011 at noon EST. >>=20 >> Thanks, >>=20 >> --John >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From warren@kumari.net Sun Nov 20 06:02:28 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 119F421F8672 for ; Sun, 20 Nov 2011 06:02:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.103 X-Spam-Level: X-Spam-Status: No, score=-106.103 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6NXOJpZXQgA for ; Sun, 20 Nov 2011 06:02:27 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 53FC821F85FF for ; Sun, 20 Nov 2011 06:02:27 -0800 (PST) Received: from [192.168.0.12] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 08CF31B404CC; Sun, 20 Nov 2011 09:02:24 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <4EC06F20.9020906@cisco.com> Date: Sat, 19 Nov 2011 17:57:28 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4897DDFA-095B-45BA-82F1-2FBC45747BA0@kumari.net> References: <7E27D7DD-8A61-43E8-904E-DEDB3B2D2C92@kumari.net> <14DD6B3A-B114-4F42-B6D0-37CC377D28C5@juniper.net> <4EC06F20.9020906@cisco.com> To: Enke Chen X-Mailer: Apple Mail (2.1084) Cc: idr@ietf.org Subject: Re: [Idr] Accept draft-wkumari-idr-as0-01.txt ? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2011 14:02:28 -0000 On Nov 13, 2011, at 8:30 PM, Enke Chen wrote: > Support, but with the following suggestions: >=20 > 1) Nit: change "bgp listener" to "bgp speaker". Thank you, done. >=20 > 2) The following language is not very precise. Due to the incremental = nature, we will need to remove the existing route too. >=20 > ----- > a BGP > listener MUST NOT accept an announcement which has an AS number of > zero in the AS-PATH attribute, and SHOULD log the fact that it has > done so. > ----- >=20 > How about the following: >=20 > An UPDATE message that contains the AS number of zero in the = AS-PATH attribute > MUST be considered as malformed, and be handled by the procedures = specified in > =20 > draft-ietf-idr-optional-transitive-04.txt >=20 > 3) If this draft is adopted, we should also add AS 0 as one of the = error conditions in > rfc4893bis. John also provided some text for that section and Keyur suggested that = we log and treat as a WITHDRAW.=20 This would read as: "This document specifies that a BGP speaker MUST NOT originate or = propagate a route with an AS number of zero. If a BGP speaker receives = a route which has an AS number of zero in the AS_PATH attribute, it = SHOULD be logged and treated as a WITHDRAW." This avoids having a normative reverence to the optional-transitive = draft and is (IMO) a little clearer. It also saves optional-transitive = from referencing this, and so we avoid the deadlock... Thoughts? W >=20 > Thanks. -- Enke >=20 >=20 > On 10/28/11 1:51 PM, John Scudder wrote: >> Folks, >>=20 >> Please send comments to the list prior to the IDR meeting on November = 15. >>=20 >> Thanks, >>=20 >> --John >>=20 >> On Oct 27, 2011, at 9:29 AM, Warren Kumari wrote: >>=20 >>=20 >>> Hello IDRites, >>>=20 >>> I would like to draw your attention to draft-wkumari-idr-as0-01.txt = (=20 >>> http://tools.ietf.org/html/draft-wkumari-idr-as0-01 >>> ) - I am asking that this draft be considered for WG adoption. >>>=20 >>>=20 >>> I have already received some feedback, mainly suggesting: >>>=20 >>> - Add a text for AS number 0 as a reserved in Aggregator and AS4 >>> Aggregator attribute >>>=20 >>> - Add text for AS number 0 as a reserved value in communities and >>> extended communities. (RFC 1997 and Four-octet AS Specific Extended >>> Communities) >>>=20 >>> Also suggested was providing a little more information on what to do = it you do receive a route containing AS0 (more descriptive than just = "MUST NOT accept" (for example, stating that it should be "excluded from = the Phase 2 decision function")). >>>=20 >>> Anyway, I would value your feedback and input. >>>=20 >>> W >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Idr mailing list >>>=20 >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr >> _______________________________________________ >> Idr mailing list >>=20 >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From shane@castlepoint.net Sun Nov 20 20:38:12 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9CA11E8093 for ; Sun, 20 Nov 2011 20:38:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.373 X-Spam-Level: X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M77A-MNRK0Tm for ; Sun, 20 Nov 2011 20:38:11 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 7194E11E808D for ; Sun, 20 Nov 2011 20:38:11 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id F02BB268063; Sun, 20 Nov 2011 21:38:00 -0700 (MST) Received: from mbpw.castlepoint.net (65-102-206-76.hlrn.qwest.net [65.102.206.76]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Sun, 20 Nov 2011 21:38:00 -0700 (MST) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=65.102.206.76; client-port=60598; syn-fingerprint=65535:54:1:64:M1452,N,W1,N,N,T,S; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: <7B61DC70-08D9-46C7-8C15-5DD339C61C2D@juniper.net> Date: Sun, 20 Nov 2011 21:37:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7B61DC70-08D9-46C7-8C15-5DD339C61C2D@juniper.net> To: John Scudder X-Mailer: Apple Mail (2.1251.1) Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-varlashkin-bgp-nh-cost-02 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: Mon, 21 Nov 2011 04:38:12 -0000 If this draft is adopted as a WG doc, I would like to see some = refinements wrt the following: 1) IIUC, the draft alludes to a situation where one can either send = regular IGP Cost in the NH_SAFI attribute -or- "(not necessarily IGP = cost, but whatever has been chosen to be carried in NH SAFI)". See also = Appendix A.2. Although I see the "simplicity" of wanting to go with = this latter direction (non-IGP cost in NH_SAFI), I think it has the = potential to create some significant operational (and/or, = implementation) hazards and thus should be considered for removal. = Unless, someone can convince us that it is, after all, "safe". More = specifically, I think: a) If a node -- let's say it's another RR client in the same = cluster -- does not understand (hasn't implemented) NH_SAFI, then how is = it supposed to receive the NH value + "special cost", which presumably = is needed at a bare minimum for routes to pass BGP's NEXT_HOP = reachability check? =20 i) At the very least, this makes an assumption and puts a = burden on the RR client to have, at the very least, a less specific = route for the NH in it's IGP (or traditional BGP) for that purpose, = which should get documented in a Operational Considerations section. ii) What's potentially more concerning is that if RR clients in = the same cluster are configured to be fully iBGP meshed, (not using = client-to-client reflection on their RR), then if one of those RR = clients can't see the NH_SAFI, then it could fall back on the IGP metric = and make an inconsistent path selection and lead to forwarding loops. b) Can an operator stick any value he/she wants for NEXT_HOP in = that field of the NH_SAFI? Or, must the implementation only send a = NEXT_HOP in NH_SAFI, when it has a valid match (IPv4 /32 or IPv6 /128?) = for that NEXT_HOP in their IGP routing table? c) Is the NH_SAFI + "special cost" only supposed to be configured = on the RR or on the RR-clients and sent to the RR? (I think it's the = latter). Regardless, it should be recommended that the RR-client must = always send a consistent NH_SAFI + "special cost" to it's redundant set = of (upstream) RR's -- or, the RR's must be configured identically with = the same NH_SAFI + "special cost" -- in order to ensure consistent path = selection at the redundant set of RR's. 2) I think the document could benefit from an "Applicability Statement" = section, which: a) More clearly articulates that this solution is primarily = intended to be used in networks whose RR's don't have full visibility to = IGP costs from the perspective of each of its clients due to well-known = issues with lack of IGP visibility due to Inter-Area or Inter-Level = summarization. b) I don't think this draft is aimed at Inter-AS use, since = presumably MED's are still sufficient in that case? Either way, that = should get clarified. 3) I also think the document could benefit from an "Operational = Considerations" section, which: a) Discusses whether changes to "Administrative Distance" are = needed at the RR's, specifically for the NH_SAFI addresses. Are these = going to be required (manually) by Operators or automatically through = the implementators of NH_SAFI so that NH_SAFI are consistently selected = for NH resolution compared to traditional IGP metric costs. For = example, on Cisco iBGP AD is 200 vs. IGP's such as OSPF or ISIS that are = at 110 and 115, respectively. (There is a very brief discussion already = in Section 3 that talks about using NH_SAFI instead of IGP cost, but = it's not clear if this is enforced through the implementation of NH_SAFI = or if it will be required of the operator to manually tune AD's to get = this 'right'). b) Recommendations that it would probably be advisable for = operators to enable and tune SPF throttling in their networks and, more = importantly, that implementations of NH_SAFI only flood "new" NH_SAFI = information _after_ an SPF has occurred. This would hopefully mitigate = a vicious feedback loop from the IGP cranking through lots of SPF's and = shoving that info into BGP toward an, already very busy, RR. Thanks, -shane On Nov 16, 2011, at 2:06 AM, John Scudder wrote: > Folks, >=20 > We have received a request from the authors to adopt = draft-varlashkin-bgp-nh-cost-02 as an IDR WG document. Please send your = comments to the list. The deadline for comments is December 5, 2011 at = noon EST. >=20 > Thanks, >=20 > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From robert@raszuk.net Mon Nov 21 00:32:51 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2970821F84DA for ; Mon, 21 Nov 2011 00:32:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zINiSnrPB2pA for ; Mon, 21 Nov 2011 00:32:50 -0800 (PST) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 152B021F8447 for ; Mon, 21 Nov 2011 00:32:49 -0800 (PST) Received: (qmail 11112 invoked by uid 399); 21 Nov 2011 08:32:48 -0000 Received: from unknown (HELO ?192.168.1.57?) (178.42.173.212) by mail1310.opentransfer.com with ESMTP; 21 Nov 2011 08:32:48 -0000 X-Originating-IP: 178.42.173.212 Message-ID: <4ECA0CAF.1080701@raszuk.net> Date: Mon, 21 Nov 2011 09:32:47 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Shane Amante References: <7B61DC70-08D9-46C7-8C15-5DD339C61C2D@juniper.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-varlashkin-bgp-nh-cost-02 as IDR WG document? 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: Mon, 21 Nov 2011 08:32:51 -0000 Hi Shane, > If this draft is adopted as a WG doc, I would like to see some > refinements wrt the following: 1) IIUC, the draft alludes to a > situation where one can either send regular IGP Cost in the NH_SAFI > attribute -or- "(not necessarily IGP cost, but whatever has been > chosen to be carried in NH SAFI)". See also Appendix A.2. Although > I see the "simplicity" of wanting to go with this latter direction > (non-IGP cost in NH_SAFI), I think it has the potential to create > some significant operational (and/or, implementation) hazards and > thus should be considered for removal. Unless, someone can convince > us that it is, after all, "safe". The addition of any arbitrary metric dates back to the discussion on the list where some folks expressed the need to have ability for manually configured "provider's policy exit selection" from any possible PE/ASBR. With tunneled networks (which are prerequisite for such policy) and minimum operational carefulness I see that much harm in allowing the next hop "metric" from a given PE to be derived by other then IGP metric means. One could be static configuration, the other could be RTT to the next hop, one could be geographic distances etc ... > More specifically, I think: a) If > a node -- let's say it's another RR client in the same cluster -- > does not understand (hasn't implemented) NH_SAFI, then how is it > supposed to receive the NH value + "special cost", which presumably > is needed at a bare minimum for routes to pass BGP's NEXT_HOP > reachability check? I would envision this SAFI to be used between RR and the client and be rather applicable to inter-cluster routes. > i) At the very least, this makes an assumption > and puts a burden on the RR client to have, at the very least, a less > specific route for the NH in it's IGP (or traditional BGP) for that > purpose, which should get documented in a Operational Considerations > section. I don't think this is required. > ii) What's potentially more concerning is that if RR clients > in the same cluster are configured to be fully iBGP meshed, (not > using client-to-client reflection on their RR), then if one of those > RR clients can't see the NH_SAFI, then it could fall back on the IGP > metric and make an inconsistent path selection and lead to forwarding > loops. Again this tool is not so much applicable to client to client. It is RR to client as optimal best path selection is a feature one would enable on RRs only. > b) Can an operator stick any value he/she wants for NEXT_HOP > in that field of the NH_SAFI? Or, must the implementation only send > a NEXT_HOP in NH_SAFI, when it has a valid match (IPv4 /32 or IPv6 > /128?) for that NEXT_HOP in their IGP routing table? The next hop must be reachable. I do not see why /32 or /128 would be required. While with MPLS encap those may already be there anyway with IP encap this is not required. > c) Is the > NH_SAFI + "special cost" only supposed to be configured on the RR or > on the RR-clients and sent to the RR? (I think it's the latter). Yes. > Regardless, it should be recommended that the RR-client must always > send a consistent NH_SAFI + "special cost" to it's redundant set of > (upstream) RR's -- or, the RR's must be configured identically with > the same NH_SAFI + "special cost" -- in order to ensure consistent > path selection at the redundant set of RR's. I agree. > 2) I think the document could benefit from an "Applicability > Statement" section, which: a) More clearly articulates that this > solution is primarily intended to be used in networks whose RR's > don't have full visibility to IGP costs from the perspective of each > of its clients due to well-known issues with lack of IGP visibility > due to Inter-Area or Inter-Level summarization. If you consider the pure metric propagation them I would agree. However some may argue that even in such cases we would like to send pure metric with NH_SAFI as only PEs/ASBRs are in position to determine if such NHs are for example labels switch paths really reachable from their location of the network. > b) I don't think > this draft is aimed at Inter-AS use, since presumably MED's are still > sufficient in that case? Either way, that should get clarified. I agree. > 3) I also think the document could benefit from an "Operational > Considerations" section, which: a) Discusses whether changes to > "Administrative Distance" are needed at the RR's, specifically for > the NH_SAFI addresses. Are these going to be required (manually) by > Operators or automatically through the implementators of NH_SAFI so > that NH_SAFI are consistently selected for NH resolution compared to > traditional IGP metric costs. The assumption was (perhaps too implicit) that NH_SAFI replaces the value which nh_metric RIB check would return for a given NH. > For example, on Cisco iBGP AD is 200 > vs. IGP's such as OSPF or ISIS that are at 110 and 115, respectively. > (There is a very brief discussion already in Section 3 that talks > about using NH_SAFI instead of IGP cost, but it's not clear if this > is enforced through the implementation of NH_SAFI or if it will be > required of the operator to manually tune AD's to get this 'right'). IMHO it should be automated. > b) Recommendations that it would probably be advisable for operators > to enable and tune SPF throttling in their networks and, more > importantly, that implementations of NH_SAFI only flood "new" NH_SAFI > information _after_ an SPF has occurred. This would hopefully > mitigate a vicious feedback loop from the IGP cranking through lots > of SPF's and shoving that info into BGP toward an, already very busy, > RR. True. NH_SAFI would flood only new information as well as it would flood them only on "significant" threshold change. Many thx for your review, R. > On Nov 16, 2011, at 2:06 AM, John Scudder wrote: >> Folks, >> >> We have received a request from the authors to adopt >> draft-varlashkin-bgp-nh-cost-02 as an IDR WG document. Please send >> your comments to the list. The deadline for comments is December >> 5, 2011 at noon EST. >> >> Thanks, >> >> --John _______________________________________________ Idr mailing >> list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ Idr mailing list > Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr > > From pierre.francois@imdea.org Mon Nov 21 00:45:25 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E59DB21F8B51 for ; Mon, 21 Nov 2011 00:45:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PD7rFxT8Aeb5 for ; Mon, 21 Nov 2011 00:45:25 -0800 (PST) Received: from estafeta.imdea.org (maquina44.madrimasd.org [193.145.15.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD4121F8B4F for ; Mon, 21 Nov 2011 00:45:25 -0800 (PST) Received: from localhost (estafeta22.imdea.org [172.17.99.146]) by estafeta22.imdea.org (Postfix) with ESMTP id 2CD6A26407B; Mon, 21 Nov 2011 09:46:01 +0100 (CET) X-Virus-Scanned: by antispam-antivirus system at imdea.org Received: from estafeta.imdea.org ([172.17.99.146]) by localhost (estafeta22.imdea.org [172.17.99.146]) (amavisd-new, port 10024) with ESMTP id nNERitxWu2kX; Mon, 21 Nov 2011 09:46:00 +0100 (CET) Received: from dory.lan (wlap006.it.uc3m.es [163.117.139.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pierre.francois) by estafeta22.imdea.org (Postfix) with ESMTP id 86A3F26407A; Mon, 21 Nov 2011 09:46:00 +0100 (CET) Message-ID: <4ECA0FA2.7010108@imdea.org> Date: Mon, 21 Nov 2011 09:45:22 +0100 From: Pierre Francois User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: John Scudder References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 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: Mon, 21 Nov 2011 08:45:26 -0000 Support. Because I (think I) understand the practical reasons for this one. Far from me the idea of enjoying IDR going along the path of protocol spec changes in order to deal with an unfortunate mix of legacy and management issues. Pierre. On 11/16/11 10:01 AM, John Scudder wrote: > Folks, > > We have received a request from the authors to adopt draft-l3vpn-legacy-rtc-00 as an IDR WG document. Please send your comments to the list. The deadline for comments is December 5, 2011 at noon EST. > > Thanks, > > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From luis.tomotaki@verizon.com Mon Nov 21 09:23:43 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E61AE11E80AA for ; Mon, 21 Nov 2011 09:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.234 X-Spam-Level: X-Spam-Status: No, score=-3.234 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ta9R-Dggn7nv for ; Mon, 21 Nov 2011 09:23:43 -0800 (PST) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA1A11E8096 for ; Mon, 21 Nov 2011 09:23:43 -0800 (PST) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by fldsmtpe02.verizon.com with ESMTP; 21 Nov 2011 17:23:42 +0000 From: "Tomotaki, Luis M." X-IronPort-AV: E=Sophos;i="4.69,548,1315180800"; d="scan'208";a="183596190" Received: from fhdp1lumxc7hb03.verizon.com (HELO FHDP1LUMXC7HB03.us.one.verizon.com) ([166.68.59.190]) by fldsmtpi03.verizon.com with ESMTP; 21 Nov 2011 17:23:41 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([169.254.1.197]) by FHDP1LUMXC7HB03.us.one.verizon.com ([166.68.59.190]) with mapi; Mon, 21 Nov 2011 12:23:41 -0500 To: "robert@raszuk.net" Date: Mon, 21 Nov 2011 12:23:40 -0500 Thread-Topic: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document? Thread-Index: AcyljmB0PSx+Xnz5QBG2+2VzYhJzUAC4Tm0w Message-ID: References: <4EC5AFB4.70804@raszuk.net> In-Reply-To: <4EC5AFB4.70804@raszuk.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 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: Mon, 21 Nov 2011 17:23:44 -0000 Robert,=20 Thanks for the feedback. I agree with your statement that more than likely= , many carriers that are supporting "legacy" PEs will not be able to run "n= ew" services on these routers. However, for most carriers, provisioning of= new circuits/VRFs on these legacy PEs continue to take place. As a carrie= r, we continue to work towards improving the overall experience of our cust= omers in these legacy PEs. =20 As it is the case in many carrier networks, automated provisioning tools on= ly have visibility to PEs and not to routers on a P or RR roles. P and RR = routers are considered core infrastructure which only a few selected groups= have access to for security issues. =20 Luis -----Original Message----- From: Robert Raszuk [mailto:robert@raszuk.net]=20 Sent: Thursday, November 17, 2011 7:07 PM To: Tomotaki, Luis M. Cc: idr@ietf.org Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document= ? Luis, > - We need support for the legacy PE draft since a large number of PEs=20 > in many service provider networks will never be able to support RFC > 4684 since the code upgrade of these legacy PEs is not an option due=20 > to multiple reasons such as end-of-life scenarios or costly hardware=20 > upgrades. Putting legacy RTC topic aside which is at the end of the day just an optim= ization it seems that your legacy PEs will also never be able to be upgrade= d with any other new functionality you or IETF may be coming with. Therefor you will not be able to run any new services on those PEs. And thi= s is all because vendor XYZ decided to abandon the software development on = a branch your and "many service providers" are using in production. That seems to me like much bigger issue that effectively this is your PE ve= ndor to get to decide what services you are to offer on your PEs. > - As a representative of a large service provider, our comment is that=20 > our provisioning systems are highly automated and should easily be=20 > able to make the provisioning changes needed to specify RT membership=20 > information on the legacy PEs during the VRF configuration with no=20 > additional risk to our customer traffic. - The > VPNV4/VPNV6 RRs in our network are considered core infrastructure=20 > devices that should NOT be exposed to daily provisioning activity that=20 > the manual addition of filters to the core RR would require. If the provisioning is "highly automated" I fail to see why provisioning in= "core infrastructure" would have to be a manual process. Best, R. From robert@raszuk.net Mon Nov 21 10:03:39 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46B0721F8B25 for ; Mon, 21 Nov 2011 10:03:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oto0nAlKvxN9 for ; Mon, 21 Nov 2011 10:03:38 -0800 (PST) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 42EE321F8B1D for ; Mon, 21 Nov 2011 10:03:38 -0800 (PST) Received: (qmail 21124 invoked by uid 399); 21 Nov 2011 18:03:37 -0000 Received: from unknown (HELO ?192.168.1.57?) (83.24.180.210) by mail1310.opentransfer.com with ESMTP; 21 Nov 2011 18:03:37 -0000 X-Originating-IP: 83.24.180.210 Message-ID: <4ECA9279.60203@raszuk.net> Date: Mon, 21 Nov 2011 19:03:37 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Tomotaki, Luis M." References: <4EC5AFB4.70804@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org" Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document? 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: Mon, 21 Nov 2011 18:03:39 -0000 Hello Luis, Many thx for your answer. One follow-up question as I am really keen to know ... > As a carrier, we continue to work towards improving the overall > experience of our customers in these legacy PEs. How does support of legacy RTC on the PE helps to improve the overall experience of your customers ? If anything I would assume this helps your core infrastructure, but customers should never see any change in experience with or without legacy RTC enabled. Best regards, R. > Robert, Thanks for the feedback. I agree with your statement that > more than likely, many carriers that are supporting "legacy" PEs > will not be able to run "new" services on these routers. However, > for most carriers, provisioning of new circuits/VRFs on these legacy > PEs continue to take place. As a carrier, we continue to work > towards improving the overall experience of our customers in these > legacy PEs. > > As it is the case in many carrier networks, automated provisioning > tools only have visibility to PEs and not to routers on a P or RR > roles. P and RR routers are considered core infrastructure which > only a few selected groups have access to for security issues. > > Luis > -----Original Message----- From: Robert Raszuk > [mailto:robert@raszuk.net] Sent: Thursday, November 17, 2011 7:07 PM > To: Tomotaki, Luis M. Cc: idr@ietf.org Subject: Re: [Idr] Adoption > of draft-l3vpn-legacy-rtc-00 as IDR WG document? > > Luis, > >> - We need support for the legacy PE draft since a large number of >> PEs in many service provider networks will never be able to >> support RFC 4684 since the code upgrade of these legacy PEs is not >> an option due to multiple reasons such as end-of-life scenarios or >> costly hardware upgrades. > > Putting legacy RTC topic aside which is at the end of the day just > an optimization it seems that your legacy PEs will also never be able > to be upgraded with any other new functionality you or IETF may be > coming with. > > Therefor you will not be able to run any new services on those PEs. > And this is all because vendor XYZ decided to abandon the software > development on a branch your and "many service providers" are using > in production. > > That seems to me like much bigger issue that effectively this is > your PE vendor to get to decide what services you are to offer on > your PEs. > >> - As a representative of a large service provider, our comment is >> that our provisioning systems are highly automated and should >> easily be able to make the provisioning changes needed to specify >> RT membership information on the legacy PEs during the VRF >> configuration with no additional risk to our customer traffic. - >> The VPNV4/VPNV6 RRs in our network are considered core >> infrastructure devices that should NOT be exposed to daily >> provisioning activity that the manual addition of filters to the >> core RR would require. > > If the provisioning is "highly automated" I fail to see why > provisioning in "core infrastructure" would have to be a manual > process. > > Best, R. > > > From stephane.litkowski@orange.com Tue Nov 22 01:48:32 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC48621F8CE3 for ; Tue, 22 Nov 2011 01:48:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=-0.297, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTg6XY7De8Jd for ; Tue, 22 Nov 2011 01:48:31 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 915DC21F8CDF for ; Tue, 22 Nov 2011 01:48:28 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 78E713B4488; Tue, 22 Nov 2011 10:48:23 +0100 (CET) Received: from puexcc31.nanterre.francetelecom.fr (unknown [10.168.74.8]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 0AAF24C071; Tue, 22 Nov 2011 10:48:23 +0100 (CET) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.46]) by puexcc31.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Nov 2011 10:48:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Nov 2011 10:48:21 +0100 Message-ID: <9098_1321955303_4ECB6FE7_9098_2388_2_4FC3556A36EE3646A09DAA60429F533507537ACF@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <4ECA9279.60203@raszuk.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document? Thread-Index: Acyod+v/RV/HzTXpR9+OHS+YF2Ur7gAgfF2w References: <4EC5AFB4.70804@raszuk.net> <4ECA9279.60203@raszuk.net> From: To: , "Tomotaki, Luis M." X-OriginalArrivalTime: 22 Nov 2011 09:48:22.0635 (UTC) FILETIME=[DF781BB0:01CCA8FB] X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.11.22.71514 Cc: idr@ietf.org Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 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: Tue, 22 Nov 2011 09:48:32 -0000 Robert, >How does support of legacy RTC on the PE helps to improve the overall expe= rience of your customers ? Here is my personal feedback on that : In some scenarios (clearing depending of vendor RR BGP code), it should opt= imize BGP update propagation time (and so end to end convergence for custom= ers) for transient update while RR is serving a route-refresh to the PE. Ro= ute-refresh will take less time to be served from RR to PE as there is less= prefixes to send, so transient update that must be served while the route-= refresh is running, will be served faster. But as I explained , it clearly = depends on how the vendor BGP code is dealing with this scenarios (serving = transient updates while RIB-out is sent due to route-refresh), but as far a= s I know (due to personal experience in this area ;) ) there is some code t= hat are causing issues ... But in this case, legacy RTC is a workaround for= BGP update propagation time, not a solution, the solution is clearly to op= timize RR code behavior. Another scenario is that , when adding a new RT in the customer VRF, it wil= l take less time to import routes into the customer VRF. It's important esp= ecially during some customer migrations (some customer support center alrea= dy reported to us some issues about time to import routes into VRFs). Last scenario, is that when PE is crashing (considering legacy PE with no N= SR or GR), it's taking time to receive routes from the RR, and during this = time, some customer (not dual homed) are isolated. Globally, when there is thousands or million VPN routes in the RR RIB-out (= especially if RR and PE are far, so there could be high RTDs and potential = few packet loss if there are low speed links on the path), it's taking minu= tes to propagate them to PE.=20 Best Regards, Stephane -----Message d'origine----- De : idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] De la part de Rober= t Raszuk Envoy=E9 : lundi 21 novembre 2011 19:04 =C0 : Tomotaki, Luis M. Cc : idr@ietf.org Objet : Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document? Hello Luis, Many thx for your answer. One follow-up question as I am really keen to kno= w ... > As a carrier, we continue to work towards improving the overall=20 > experience of our customers in these legacy PEs. How does support of legacy RTC on the PE helps to improve the overall exper= ience of your customers ? If anything I would assume this helps your core infrastructure, but custome= rs should never see any change in experience with or without legacy RTC ena= bled. Best regards, R. > Robert, Thanks for the feedback. I agree with your statement that=20 > more than likely, many carriers that are supporting "legacy" PEs will=20 > not be able to run "new" services on these routers. However, for most=20 > carriers, provisioning of new circuits/VRFs on these legacy PEs=20 > continue to take place. As a carrier, we continue to work towards=20 > improving the overall experience of our customers in these legacy PEs. > > As it is the case in many carrier networks, automated provisioning=20 > tools only have visibility to PEs and not to routers on a P or RR=20 > roles. P and RR routers are considered core infrastructure which only=20 > a few selected groups have access to for security issues. > > Luis > -----Original Message----- From: Robert Raszuk=20 > [mailto:robert@raszuk.net] Sent: Thursday, November 17, 2011 7:07 PM > To: Tomotaki, Luis M. Cc: idr@ietf.org Subject: Re: [Idr] Adoption of=20 > draft-l3vpn-legacy-rtc-00 as IDR WG document? > > Luis, > >> - We need support for the legacy PE draft since a large number of PEs=20 >> in many service provider networks will never be able to support RFC=20 >> 4684 since the code upgrade of these legacy PEs is not an option due=20 >> to multiple reasons such as end-of-life scenarios or costly hardware=20 >> upgrades. > > Putting legacy RTC topic aside which is at the end of the day just an=20 > optimization it seems that your legacy PEs will also never be able to=20 > be upgraded with any other new functionality you or IETF may be coming=20 > with. > > Therefor you will not be able to run any new services on those PEs. > And this is all because vendor XYZ decided to abandon the software=20 > development on a branch your and "many service providers" are using in=20 > production. > > That seems to me like much bigger issue that effectively this is your=20 > PE vendor to get to decide what services you are to offer on your PEs. > >> - As a representative of a large service provider, our comment is=20 >> that our provisioning systems are highly automated and should easily=20 >> be able to make the provisioning changes needed to specify RT=20 >> membership information on the legacy PEs during the VRF configuration=20 >> with no additional risk to our customer traffic. - The VPNV4/VPNV6=20 >> RRs in our network are considered core infrastructure devices that=20 >> should NOT be exposed to daily provisioning activity that the manual=20 >> addition of filters to the core RR would require. > > If the provisioning is "highly automated" I fail to see why=20 > provisioning in "core infrastructure" would have to be a manual=20 > process. > > Best, R. > > > _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, France Telecom - = Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorization. If you have received this email in error,= please notify the sender and delete this message and its attachments. As e= mails may be altered, France Telecom - Orange shall not be liable if this m= essage was modified, changed or falsified. Thank you. From robert@raszuk.net Tue Nov 22 02:07:43 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5783621F8D66 for ; Tue, 22 Nov 2011 02:07:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id faKYqgQ7pLza for ; Tue, 22 Nov 2011 02:07:42 -0800 (PST) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 62F0221F8D5D for ; Tue, 22 Nov 2011 02:07:42 -0800 (PST) Received: (qmail 31997 invoked by uid 399); 22 Nov 2011 10:07:41 -0000 Received: from unknown (HELO ?192.168.1.57?) (83.24.194.121) by mail1310.opentransfer.com with ESMTP; 22 Nov 2011 10:07:41 -0000 X-Originating-IP: 83.24.194.121 Message-ID: <4ECB746D.8000307@raszuk.net> Date: Tue, 22 Nov 2011 11:07:41 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: stephane.litkowski@orange.com References: <4EC5AFB4.70804@raszuk.net> <4ECA9279.60203@raszuk.net> <9098_1321955303_4ECB6FE7_9098_2388_2_4FC3556A36EE3646A09DAA60429F533507537ACF@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <9098_1321955303_4ECB6FE7_9098_2388_2_4FC3556A36EE3646A09DAA60429F533507537ACF@PUEXCBL0.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 10:07:43 -0000 Hi Stephane, Few comments ... > In some scenarios (clearing depending of vendor RR BGP code), it > should optimize BGP update propagation time (and so end to end > convergence for customers) for transient update while RR is serving a > route-refresh to the PE. Route-refresh will take less time to be > served from RR to PE as there is less prefixes to send, so transient > update that must be served while the route-refresh is running, will > be served faster. But as I explained , it clearly depends on how the > vendor BGP code is dealing with this scenarios (serving transient > updates while RIB-out is sent due to route-refresh), but as far as I > know (due to personal experience in this area ;) ) there is some code > that are causing issues ... But in this case, legacy RTC is a > workaround for BGP update propagation time, not a solution, the > solution is clearly to optimize RR code behavior. Let me point out that RT-Constrain only triggers reception of what is needed by the PE when new RT is added or deleted. If legacy RTC still requires to send route refresh from the PE that means that such PE each time RT change occurs will be still bombarded with all VPNv4/v6 routes as specified in route-target filter list for a given entire PE. Agreed that this may be less then overall amount of VPNv4 routes stored on the RR however this is much much more then needed by PE by any given atomic RT change. > Another scenario is that , when adding a new RT in the customer VRF, > it will take less time to import routes into the customer VRF. It's > important especially during some customer migrations (some customer > support center already reported to us some issues about time to > import routes into VRFs). I assume this "time difference" is due to a fact that PE will be receiving only subset of all VPN routes in the network ... but still much more then would be needed for newly modified customer VRF. But again this is the same "gain" as above. > Last scenario, is that when PE is crashing (considering legacy PE > with no NSR or GR), it's taking time to receive routes from the RR, > and during this time, some customer (not dual homed) are isolated. > > Globally, when there is thousands or million VPN routes in the RR > RIB-out (especially if RR and PE are far, so there could be high RTDs > and potential few packet loss if there are low speed links on the > path), it's taking minutes to propagate them to PE. If as you say there is no NSR/GR on the RR I do not know how you are going to accomplish that benefit. AFAIK there is no mechanism on _existing_ PEs to mandate that routes from some VRFs are send before routes from other VRFs. So effectively your special VRF's filters may be send last and RR will not wait after session is establish, but will start sending "thousands or million VPN routes" towards restarting PE. That is why we have specifically added a capability to RFC4684 to protect from this case by waiting for RTC to send filters first once RTC capability has been negotiated. Regards, R. From stephane.litkowski@orange.com Tue Nov 22 02:33:24 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03DCA21F8D44 for ; Tue, 22 Nov 2011 02:33:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXpe-MCTcbJ1 for ; Tue, 22 Nov 2011 02:33:23 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 1398121F8D40 for ; Tue, 22 Nov 2011 02:33:23 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 05B0722C42F; Tue, 22 Nov 2011 11:33:22 +0100 (CET) Received: from PUEXCC21.nanterre.francetelecom.fr (unknown [10.168.72.145]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id C63CC27C06E; Tue, 22 Nov 2011 11:33:21 +0100 (CET) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.46]) by PUEXCC21.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Nov 2011 11:33:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Nov 2011 11:33:20 +0100 Message-ID: <24873_1321958001_4ECB7A71_24873_12279_2_4FC3556A36EE3646A09DAA60429F533507537B5E@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <4ECB746D.8000307@raszuk.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document? Thread-Index: Acyo/pYtY8lp0hifQsG35yq5F8hDcAAAu1Pg References: <4EC5AFB4.70804@raszuk.net> <4ECA9279.60203@raszuk.net> <9098_1321955303_4ECB6FE7_9098_2388_2_4FC3556A36EE3646A09DAA60429F533507537ACF@PUEXCBL0.nanterre.francetelecom.fr> <4ECB746D.8000307@raszuk.net> From: To: X-OriginalArrivalTime: 22 Nov 2011 10:33:22.0104 (UTC) FILETIME=[287A6380:01CCA902] X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.11.22.71514 Cc: idr@ietf.org Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 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: Tue, 22 Nov 2011 10:33:24 -0000 >Let me point out that RT-Constrain only triggers reception of what is need= ed by the PE when new RT is added or deleted. If legacy RTC still requires = to >send route refresh from the PE that means that such PE each time RT cha= nge occurs will be still bombarded with all VPNv4/v6 routes as specified in= =20 >route-target filter list for a given entire PE. >Agreed that this may be less then overall amount of VPNv4 routes stored on= the RR however this is much much more then needed by PE by any given atomi= c RT >change. [SLI] you are right, it's not as optimal as RTC is able to do, but it's les= s than the entire RIB out (between 30% and 60% of the entire RIB-out for us= , depending of the PE config/load) >assume this "time difference" is due to a fact that PE will be receiving = only subset of all VPN routes in the network ... but still much more then w= ould >be needed for newly modified customer VRF. But again this is the same= "gain" as above. [SLI] Yes >If as you say there is no NSR/GR on the RR I do not know how you are going= to accomplish that benefit. AFAIK there is no mechanism on _existing_ PEs = to=20 >mandate that routes from some VRFs are send before routes from other VRFs.= So effectively your special VRF's filters may be send last and RR will not= =20 >wait after session is establish, but will start sending "thousands or mill= ion VPN routes" towards restarting PE. [SLI] You are right, I missed that point, there is no VRF priorisation when= sending routes, so legacy RTC has no effect at session startup (while RTC = is doing this well, as you mentionned). Best Regards, Stephane -----Message d'origine----- De : Robert Raszuk [mailto:robert@raszuk.net]=20 Envoy=E9 : mardi 22 novembre 2011 11:08 =C0 : LITKOWSKI Stephane DTF/DERX Cc : Tomotaki, Luis M.; idr@ietf.org Objet : Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document? Hi Stephane, Few comments ... > In some scenarios (clearing depending of vendor RR BGP code), it=20 > should optimize BGP update propagation time (and so end to end=20 > convergence for customers) for transient update while RR is serving a=20 > route-refresh to the PE. Route-refresh will take less time to be=20 > served from RR to PE as there is less prefixes to send, so transient=20 > update that must be served while the route-refresh is running, will be=20 > served faster. But as I explained , it clearly depends on how the=20 > vendor BGP code is dealing with this scenarios (serving transient=20 > updates while RIB-out is sent due to route-refresh), but as far as I=20 > know (due to personal experience in this area ;) ) there is some code=20 > that are causing issues ... But in this case, legacy RTC is a=20 > workaround for BGP update propagation time, not a solution, the=20 > solution is clearly to optimize RR code behavior. Let me point out that RT-Constrain only triggers reception of what is neede= d by the PE when new RT is added or deleted. If legacy RTC still requires t= o send route refresh from the PE that means that such PE each time RT chang= e occurs will be still bombarded with all VPNv4/v6 routes as specified in r= oute-target filter list for a given entire PE. Agreed that this may be less then overall amount of VPNv4 routes stored on = the RR however this is much much more then needed by PE by any given atomic= RT change. > Another scenario is that , when adding a new RT in the customer VRF,=20 > it will take less time to import routes into the customer VRF. It's=20 > important especially during some customer migrations (some customer=20 > support center already reported to us some issues about time to import=20 > routes into VRFs). I assume this "time difference" is due to a fact that PE will be receiving = only subset of all VPN routes in the network ... but still much more then w= ould be needed for newly modified customer VRF. But again this is the same = "gain" as above. > Last scenario, is that when PE is crashing (considering legacy PE with=20 > no NSR or GR), it's taking time to receive routes from the RR, and=20 > during this time, some customer (not dual homed) are isolated. > > Globally, when there is thousands or million VPN routes in the RR=20 > RIB-out (especially if RR and PE are far, so there could be high RTDs=20 > and potential few packet loss if there are low speed links on the=20 > path), it's taking minutes to propagate them to PE. If as you say there is no NSR/GR on the RR I do not know how you are going = to accomplish that benefit. AFAIK there is no mechanism on _existing_ PEs t= o mandate that routes from some VRFs are send before routes from other VRFs= . So effectively your special VRF's filters may be send last and RR will no= t wait after session is establish, but will start sending "thousands or mil= lion VPN routes" towards restarting PE. That is why we have specifically added a capability to RFC4684 to protect f= rom this case by waiting for RTC to send filters first once RTC capability = has been negotiated. Regards, R. ___________________________________________________________________________= ______________________________________________ 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. Le= s messages electroniques etant susceptibles d'alteration, France Telecom - = Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorization. If you have received this email in error,= please notify the sender and delete this message and its attachments. As e= mails may be altered, France Telecom - Orange shall not be liable if this m= essage was modified, changed or falsified. Thank you. From bruno.decraene@orange.com Tue Nov 22 06:48:27 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFFC21F8C99 for ; Tue, 22 Nov 2011 06:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.189 X-Spam-Level: X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[AWL=2.060, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMamXckMLIex for ; Tue, 22 Nov 2011 06:48:26 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 9A95621F8C8E for ; Tue, 22 Nov 2011 06:48:26 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 98CBD340003; Tue, 22 Nov 2011 15:48:24 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 8DA39340001; Tue, 22 Nov 2011 15:48:24 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Nov 2011 15:48:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Nov 2011 15:48:23 +0100 Message-ID: In-Reply-To: <4EC32C36.8070902@riw.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-00 Thread-Index: AcykDtz5gMgIU07kSjaciAI+tzczqAE58UEQ References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net><4EA84254.9000400@raszuk.net> <4EA8A91C.4090305@cisco.com><4EAA496C.9070605@cisco.com><4EC21062.5020504@raszuk.net><4EC28B45.1040509@raszuk.net> <4EC32C36.8070902@riw.us> From: To: X-OriginalArrivalTime: 22 Nov 2011 14:48:24.0798 (UTC) FILETIME=[C9982FE0:01CCA925] Cc: idr@ietf.org, ju1738@att.com Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 14:48:27 -0000 Russ, >From: Russ White, Sent: Wednesday, November 16, 2011 4:21 AM > >> I am personally completely not convinced that there is any value in >> informing my peers that one of my BGP sessions went down. You either >> have reachability to next hop and can attract traffic or you do not and >> if so you withdraw. >> >> Telling peers that "I may be perhaps used to reach prefix X as last >> resort" is of highly questionable value. > >I would go farther --this isn't questionable, it's really bad. If you >have a route you know exists, but you don't want people to use, set >things so it's a "last resort" (wait for BGP, wait for LDP, etc). If you >don't know whether or not you really have reachability, don't advertise it. As you don't comment on Graceful Restart (GR), I assume that you are fine with GR. Are you? Then I think we need to make a distinction between the information we have on a route, and the routing decision we make based on those information. a) failure assumption: let's assume a PE can lose both its iBGP session toward its redundant RR Note: the assumption is the same for GR and persistence. b) information available: Once the BGP session(s) are down, we have the following information available on the BGP router: cause of failure, route tags, time (t) elapsed since the session failure, local configuration/preference Note: idem for GR and persistence. At that point, I would say that once t>0, we have no certainty on the validity of the route (from the BGP peer/BGP Next-Hop and from downstream BGP routers). And the longer the duration, the less certainty. Note: for a given "t", this is the same for GR and persistence. Hence I don't get how you claim that "it's really bad" for persistence while it's ok for GR. c) routing decision: Given the above information and level of uncertainty, at a given "t" time, currently 2 routing decisions are possible: - withdraw the route. - This is the regular BGP behavior.=20 - The reasoning is that the level of uncertainty is too high to use that route. - keep the route. - This is the BGP Graceful Restart behavior.=20 - The reasoning is that the level of uncertainty is low enough so that the route can still be considered perfectly valid. But the router making the above decision is the BGP advertising router hence the egress router. It's lacking some information only available on the ingress router. Namely the availability of alternate paths/Next Hop on the ingress. I call that this is an important information to make the routing decision. Because in the end, each router/AS tries to take the _best_ decision among _available_ options. This is not a binary decision between "right/good" and "bad". So compared to GR, BGP persistence proposes to give some additional information and routing decision on upstream ingress BGP routers. (e.g. using "STALE" community, low BGP local pref. But other vehicles could be considered). Could you elaborate on why this would be "really bad"? Thanks, Regards, Bruno >The possible problems involved in saying, "I might have a route to x, >just in case you don't have any other path there," will end up being >really, really ugly. > >:-) > >Russ >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From robert@raszuk.net Tue Nov 22 10:06:16 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9325D21F8B9C for ; Tue, 22 Nov 2011 10:06:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQut9HjyAhbY for ; Tue, 22 Nov 2011 10:06:15 -0800 (PST) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 9779821F8B9A for ; Tue, 22 Nov 2011 10:06:15 -0800 (PST) Received: (qmail 26653 invoked by uid 399); 22 Nov 2011 18:06:14 -0000 Received: from unknown (HELO ?192.168.1.57?) (83.24.194.121) by mail1310.opentransfer.com with ESMTP; 22 Nov 2011 18:06:14 -0000 X-Originating-IP: 83.24.194.121 Message-ID: <4ECBE495.4070006@raszuk.net> Date: Tue, 22 Nov 2011 19:06:13 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: bruno.decraene@orange.com References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net><4EA84254.9000400@raszuk.net> <4EA8A91C.4090305@cisco.com><4EAA496C.9070605@cisco.com><4EC21062.5020504@raszuk.net><4EC28B45.1040509@raszuk.net> <4EC32C36.8070902@riw.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org, ju1738@att.com Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 18:06:16 -0000 Hi Bruno, Great comparison between GR and persistent ! However there is significant two points which need to be highlighted ... 1. - time t for GR is max expressed as 12 bits in seconds which is 68 min ... if session does not come up for that long I think it is wise to clean up - time t for persistence is indicated in the draft to be in case of L2VPN: "The persist-timer should be set to a large value on the order of days to infinity." In case of L3VPN: "The persist-timer should be set to a large value on the order of hours to a few days." 2. In both GR and persistance the key to using the path on BGP speakers in the data plane is in next hop liveness detection. Be it in scope of the draft or out of scope does not really matter. Ingress as you call it should not care if RR says this path is suspicious if he can reach just fine the next hop of the prefix. So this is not that we like GR and we do not like persistence. All we are saying is that the only real delta between GR and persistance is this new signalling informing that path is "perhaps broken". This is this "perhaps" which many folks have a problem with. Best regards, R. > Russ, > >> From: Russ White, Sent: Wednesday, November 16, 2011 4:21 AM >> >>> I am personally completely not convinced that there is any value in >>> informing my peers that one of my BGP sessions went down. You either >>> have reachability to next hop and can attract traffic or you do not > and >>> if so you withdraw. >>> >>> Telling peers that "I may be perhaps used to reach prefix X as last >>> resort" is of highly questionable value. >> >> I would go farther --this isn't questionable, it's really bad. If you >> have a route you know exists, but you don't want people to use, set >> things so it's a "last resort" (wait for BGP, wait for LDP, etc). If > you >> don't know whether or not you really have reachability, don't advertise > it. > > As you don't comment on Graceful Restart (GR), I assume that you are > fine with GR. > Are you? > > Then I think we need to make a distinction between the information we > have on a route, and the routing decision we make based on those > information. > > a) failure assumption: > let's assume a PE can lose both its iBGP session toward its redundant RR > Note: the assumption is the same for GR and persistence. > > b) information available: > Once the BGP session(s) are down, we have the following information > available on the BGP router: cause of failure, route tags, time (t) > elapsed since the session failure, local configuration/preference > Note: idem for GR and persistence. > > At that point, I would say that once t>0, we have no certainty on the > validity of the route (from the BGP peer/BGP Next-Hop and from > downstream BGP routers). And the longer the duration, the less > certainty. > Note: for a given "t", this is the same for GR and persistence. Hence I > don't get how you claim that "it's really bad" for persistence while > it's ok for GR. > > c) routing decision: > Given the above information and level of uncertainty, at a given "t" > time, currently 2 routing decisions are possible: > - withdraw the route. > - This is the regular BGP behavior. > - The reasoning is that the level of uncertainty is too high to > use that route. > - keep the route. > - This is the BGP Graceful Restart behavior. > - The reasoning is that the level of uncertainty is low enough > so that the route can still be considered perfectly valid. > > > But the router making the above decision is the BGP advertising router > hence the egress router. It's lacking some information only available on > the ingress router. Namely the availability of alternate paths/Next Hop > on the ingress. I call that this is an important information to make the > routing decision. Because in the end, each router/AS tries to take the > _best_ decision among _available_ options. This is not a binary decision > between "right/good" and "bad". So compared to GR, BGP persistence > proposes to give some additional information and routing decision on > upstream ingress BGP routers. (e.g. using "STALE" community, low BGP > local pref. But other vehicles could be considered). > > Could you elaborate on why this would be "really bad"? > > Thanks, > Regards, > Bruno > >> The possible problems involved in saying, "I might have a route to x, >> just in case you don't have any other path there," will end up being >> really, really ugly. >> >> :-) >> >> Russ >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > From bruno.decraene@orange.com Wed Nov 23 03:18:35 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6434E21F8B37 for ; Wed, 23 Nov 2011 03:18:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.716 X-Spam-Level: X-Spam-Status: No, score=-4.716 tagged_above=-999 required=5 tests=[AWL=1.533, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SiO-N4FVuZhj for ; Wed, 23 Nov 2011 03:18:34 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 551AF21F8B2B for ; Wed, 23 Nov 2011 03:18:34 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3DF2D8F0003; Wed, 23 Nov 2011 12:19:38 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 32C178B8001; Wed, 23 Nov 2011 12:19:38 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Nov 2011 12:18:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Nov 2011 12:18:31 +0100 Message-ID: In-Reply-To: <4ECBE495.4070006@raszuk.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-00 Thread-Index: AcypQW9wfR2AkjRdRK+AhV1B9ZuOtwAiUr2g References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net><4EA84254.9000400@raszuk.net> <4EA8A91C.4090305@cisco.com><4EAA496C.9070605@cisco.com><4EC21062.5020504@raszuk.net><4EC28B45.1040509@raszuk.net> <4EC32C36.8070902@riw.us> <4ECBE495.4070006@raszuk.net> From: To: X-OriginalArrivalTime: 23 Nov 2011 11:18:33.0250 (UTC) FILETIME=[A2DC3020:01CCA9D1] Cc: idr@ietf.org, ju1738@att.com Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 11:18:35 -0000 Hi Robert, >Hi Bruno, > >Great comparison between GR and persistent ! > > >However there is significant two points which need to be highlighted ... > >1. > >- time t for GR is max expressed as 12 bits in seconds which is 68 min >... if session does not come up for that long I think it is wise to >clean up > >- time t for persistence is indicated in the draft to be in case of >L2VPN: "The persist-timer should be set to a large value on the order of >days to infinity." In case of L3VPN: "The persist-timer should be set to >a large value on the order of hours to a few days." If you believe 68 minutes is the right max value, - IMHO Max timer duration should be AS and application specific. There is no right value. That's also the position taken by GR. Especially as some routes may be rather static. - Where does 68 minutes come from? Why would this be the right value? Why are you more restrictive than the BGP RFC (Hold Time)? - for consistency, I guess you will also argue against defining a long timer value in the GR respin draft as has been proposed during the meeting. >2. > >In both GR and persistance the key to using the path on BGP speakers in >the data plane is in next hop liveness detection. Be it in scope of the >draft or out of scope does not really matter. Ingress as you call it >should not care if RR says this path is suspicious if he can reach just >fine the next hop of the prefix. No. BGP Next-Hop liveliness is important and need to be checked. But this only one part of the route validity problem as this only checks the BGP Next-Hop /ASBR. Any downstream BGP routers could withdraw the route. You/egress/ingress would not know as the BGP session is down. Hence it's important to mark this path (as "stale" or "not refreshed" if you prefer) and ingress should care. >So this is not that we like GR and we do not like persistence. All we >are saying is that the only real delta between GR and persistance is >this new signalling informing that path is "perhaps broken". This is >this "perhaps" which many folks have a problem with. > > >Best regards, >R. > > >> Russ, >> >>> From: Russ White, Sent: Wednesday, November 16, 2011 4:21 AM >>> >>>> I am personally completely not convinced that there is any value in >>>> informing my peers that one of my BGP sessions went down. You either >>>> have reachability to next hop and can attract traffic or you do not >> and >>>> if so you withdraw. >>>> >>>> Telling peers that "I may be perhaps used to reach prefix X as last >>>> resort" is of highly questionable value. >>> >>> I would go farther --this isn't questionable, it's really bad. If you >>> have a route you know exists, but you don't want people to use, set >>> things so it's a "last resort" (wait for BGP, wait for LDP, etc). If >> you >>> don't know whether or not you really have reachability, don't advertise >> it. >> >> As you don't comment on Graceful Restart (GR), I assume that you are >> fine with GR. >> Are you? >> >> Then I think we need to make a distinction between the information we >> have on a route, and the routing decision we make based on those >> information. >> >> a) failure assumption: >> let's assume a PE can lose both its iBGP session toward its redundant RR >> Note: the assumption is the same for GR and persistence. >> >> b) information available: >> Once the BGP session(s) are down, we have the following information >> available on the BGP router: cause of failure, route tags, time (t) >> elapsed since the session failure, local configuration/preference >> Note: idem for GR and persistence. >> >> At that point, I would say that once t>0, we have no certainty on the >> validity of the route (from the BGP peer/BGP Next-Hop and from >> downstream BGP routers). And the longer the duration, the less >> certainty. >> Note: for a given "t", this is the same for GR and persistence. Hence I >> don't get how you claim that "it's really bad" for persistence while >> it's ok for GR. >> >> c) routing decision: >> Given the above information and level of uncertainty, at a given "t" >> time, currently 2 routing decisions are possible: >> - withdraw the route. >> - This is the regular BGP behavior. >> - The reasoning is that the level of uncertainty is too high to >> use that route. >> - keep the route. >> - This is the BGP Graceful Restart behavior. >> - The reasoning is that the level of uncertainty is low enough >> so that the route can still be considered perfectly valid. >> >> >> But the router making the above decision is the BGP advertising router >> hence the egress router. It's lacking some information only available on >> the ingress router. Namely the availability of alternate paths/Next Hop >> on the ingress. I call that this is an important information to make the >> routing decision. Because in the end, each router/AS tries to take the >> _best_ decision among _available_ options. This is not a binary decision >> between "right/good" and "bad". So compared to GR, BGP persistence >> proposes to give some additional information and routing decision on >> upstream ingress BGP routers. (e.g. using "STALE" community, low BGP >> local pref. But other vehicles could be considered). >> >> Could you elaborate on why this would be "really bad"? >> >> Thanks, >> Regards, >> Bruno >> >>> The possible problems involved in saying, "I might have a route to x, >>> just in case you don't have any other path there," will end up being >>> really, really ugly. >>> >>> :-) >>> >>> Russ >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> >> From anton.elita@tinet.net Wed Nov 23 08:05:06 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3699221F8B90 for ; Wed, 23 Nov 2011 08:05:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+sbO1CYQV+M for ; Wed, 23 Nov 2011 08:05:05 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1406321F8440 for ; Wed, 23 Nov 2011 08:05:04 -0800 (PST) Received: by iaeo4 with SMTP id o4so2098211iae.31 for ; Wed, 23 Nov 2011 08:05:04 -0800 (PST) Received: by 10.43.45.137 with SMTP id uk9mr3225745icb.52.1322064304148; Wed, 23 Nov 2011 08:05:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.57.129 with HTTP; Wed, 23 Nov 2011 08:04:43 -0800 (PST) In-Reply-To: <7B61DC70-08D9-46C7-8C15-5DD339C61C2D@juniper.net> References: <7B61DC70-08D9-46C7-8C15-5DD339C61C2D@juniper.net> From: Anton Elita Date: Wed, 23 Nov 2011 17:04:43 +0100 Message-ID: To: "idr@ietf.org List" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Idr] Adoption of draft-varlashkin-bgp-nh-cost-02 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: Wed, 23 Nov 2011 16:05:06 -0000 Support --=20 Anton Elita Tinet On Wed, Nov 16, 2011 at 10:06 AM, John Scudder wrote: > Folks, > > We have received a request from the authors to adopt draft-varlashkin-bgp= -nh-cost-02 as an IDR WG document. =A0Please send your comments to the list= . =A0The deadline for comments is December 5, 2011 at noon EST. > > Thanks, > > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From iesg-secretary@ietf.org Thu Nov 24 16:53:42 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5D521F8B18; Thu, 24 Nov 2011 16:53:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fyh4PmQwxEat; Thu, 24 Nov 2011 16:53:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3AAC21F8AF9; Thu, 24 Nov 2011 16:53:41 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64 Message-ID: <20111125005341.3886.68531.idtracker@ietfa.amsl.com> Date: Thu, 24 Nov 2011 16:53:41 -0800 Cc: idr@ietf.org Subject: [Idr] Last Call: (Subcodes for BGP Finite State Machine Error) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 00:53:42 -0000 The IESG has received a request from the Inter-Domain Routing WG (idr) to consider the following document: - 'Subcodes for BGP Finite State Machine Error' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-12-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines several subcodes for BGP Finite State Machine (FSM) Error that could provide more information to help network operators in diagnosing BGP FSM issues and correlating network events. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-idr-fsm-subcode/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-idr-fsm-subcode/ No IPR declarations have been submitted directly on this I-D. From internet-drafts@ietf.org Fri Nov 25 11:08:09 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 284EA21F85EF; Fri, 25 Nov 2011 11:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aS75duIYSqDE; Fri, 25 Nov 2011 11:08:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9F4021F84FD; Fri, 25 Nov 2011 11:08:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64 Message-ID: <20111125190808.24097.31951.idtracker@ietfa.amsl.com> Date: Fri, 25 Nov 2011 11:08:08 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-add-paths-guidelines-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 19:08:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of= the IETF. Title : Best Practices for Advertisement of Multiple Paths in IB= GP Author(s) : Jim Uttaro Virginie Van den Schrieck Pierre Francois Roberto Fragassi Adam Simpson Pradosh Mohapatra Filename : draft-ietf-idr-add-paths-guidelines-02.txt Pages : 22 Date : 2011-11-25 Add-Paths is a BGP enhancement that allows a BGP router to advertise multiple distinct paths for the same prefix/NLRI. This provides a number of potential benefits, including reduced routing churn, faster convergence and better loadsharing. This document provides recommendations to implementers of Add-Paths so that network operators have the tools needed to address their specific applications and to manage the scalability impact of Add- Paths. A router implementing Add-Paths may learn many paths for a prefix and must decide which of these to advertise to peers. This document analyses different algorithms for making this selection and provides recommendations based on the target application. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-add-paths-guidelines-02.= txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-add-paths-guidelines-02.t= xt From adam.simpson@alcatel-lucent.com Fri Nov 25 11:32:35 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB6F721F8B05 for ; Fri, 25 Nov 2011 11:32:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPjEmXRbA21x for ; Fri, 25 Nov 2011 11:32:35 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id EA35A21F8B01 for ; Fri, 25 Nov 2011 11:32:34 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id pAPJWYEn017931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 25 Nov 2011 13:32:34 -0600 (CST) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pAPJWXl6030194 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 25 Nov 2011 13:32:34 -0600 Received: from USNAVSXCHMBSC1.ndc.alcatel-lucent.com ([135.3.39.145]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Fri, 25 Nov 2011 13:32:33 -0600 From: "Simpson, Adam (Adam)" To: "idr@ietf.org" Date: Fri, 25 Nov 2011 13:32:32 -0600 Thread-Topic: [Idr] I-D Action: draft-ietf-idr-add-paths-guidelines-02.txt Thread-Index: AcyrpbaKXNtfPKPdSjy0iN7tRdnR7wAAGkYw Message-ID: References: <20111125190808.24097.31951.idtracker@ietfa.amsl.com> In-Reply-To: <20111125190808.24097.31951.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [Idr] I-D Action: draft-ietf-idr-add-paths-guidelines-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 19:32:36 -0000 This is a minor update from the -01 version. The authors would appreciate feedback on this latest version. For those tha= t have not read the draft it attempts to fill in details about the differen= t use cases for Add-Paths, the configuration flexibility required by these = use cases, and related interoperability considerations. Any feedback is wel= come but input on the specific questions below would be particularly helpfu= l. Path selection modes: 1. A while ago a suggestion was made that the document consider an Add-N-be= st-external mode. The authors have discussed this and believe such a mode d= oes not offer useful value above and beyond the Add-N mode. 2. We discussed at the IETF81 meeting the potential value of a new path sel= ection mode that selects all paths or the N best paths with a specific comm= unity value. The authors are inclined to add this new mode to a future vers= ion of the draft. Are there strong views for or against inclusion of this n= ew mode? 3. Beyond the new mode discussed in the previous point, there are no plans = to document any further path selection modes. If there is a compelling use = case for a mode we have not considered this should be brought to our attent= ion either on- or off-list. Changes to the Add-Paths capability: 1. The Add-Paths capability, as currently defined in draft-ietf-idr-add-pat= hs, provides no means of signaling the max number of paths per prefix the l= ocal speaker would like to receive from its Add-Paths capable neighbor. Rou= ters in certain roles may have a soft or hard constraint about the number o= f paths per prefix they want to receive from selected peers, and could sign= al this constraint on a per AFI/SAFI basis to help the sender with its path= selection. Would it be useful to extend the Add-Paths capability to includ= e this max paths request? As usual, the routing consistency risks of advert= ising a different set of paths to different neighbors must be carefully con= sidered. Regards, Authors > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Friday, November 25, 2011 2:08 PM > To: i-d-announce@ietf.org > Cc: idr@ietf.org > Subject: [Idr] I-D Action: draft-ietf-idr-add-paths-guidelines-02.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Inter-Domain Routing > Working Group of the IETF. >=20 > Title : Best Practices for Advertisement of Multiple > Paths in IBGP > Author(s) : Jim Uttaro > Virginie Van den Schrieck > Pierre Francois > Roberto Fragassi > Adam Simpson > Pradosh Mohapatra > Filename : draft-ietf-idr-add-paths-guidelines-02.txt > Pages : 22 > Date : 2011-11-25 >=20 > Add-Paths is a BGP enhancement that allows a BGP router to advertise > multiple distinct paths for the same prefix/NLRI. This provides a > number of potential benefits, including reduced routing churn, > faster > convergence and better loadsharing. >=20 > This document provides recommendations to implementers of Add-Paths > so that network operators have the tools needed to address their > specific applications and to manage the scalability impact of Add- > Paths. A router implementing Add-Paths may learn many paths for a > prefix and must decide which of these to advertise to peers. This > document analyses different algorithms for making this selection and > provides recommendations based on the target application. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-idr-add-paths- > guidelines-02.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-add-paths-guidelines- > 02.txt >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From ju1738@att.com Sat Nov 26 06:33:53 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6793B21F8B04 for ; Sat, 26 Nov 2011 06:33:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.222 X-Spam-Level: X-Spam-Status: No, score=-106.222 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QOoOGYSLuTps for ; Sat, 26 Nov 2011 06:33:52 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5A121F8B03 for ; Sat, 26 Nov 2011 06:33:52 -0800 (PST) X-Env-Sender: ju1738@att.com X-Msg-Ref: server-14.tower-119.messagelabs.com!1322318029!2916462!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25971 invoked from network); 26 Nov 2011 14:33:49 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-14.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Nov 2011 14:33:49 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pAQEYHjb030576; Sat, 26 Nov 2011 09:34:18 -0500 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (misout7msghub9c.itservices.sbc.com [144.151.223.82]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pAQEYEvw030560 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 26 Nov 2011 09:34:15 -0500 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([169.254.1.53]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.01.0339.001; Sat, 26 Nov 2011 09:33:46 -0500 From: "UTTARO, JAMES" To: "'Anton Elita'" , "idr@ietf.org List" Thread-Topic: [Idr] Adoption of draft-varlashkin-bgp-nh-cost-02 as IDR WG document? Thread-Index: AcykPwG7jl6Kwgf+R0CL/omsorSMmQF5IPuAAIh6m/A= Date: Sat, 26 Nov 2011 14:33:45 +0000 Message-ID: References: <7B61DC70-08D9-46C7-8C15-5DD339C61C2D@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.177.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] Adoption of draft-varlashkin-bgp-nh-cost-02 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: Sat, 26 Nov 2011 14:33:53 -0000 Do not support. Jim Uttaro Ilya, Apologies for not responding sooner.. I do have some questions in re the d= raft.. 1. Motivation "ADDPATH solves this problem by letting route-reflector to advertise multiple paths for given prefix. If number of advertised paths sufficiently big, route-reflector clients can choose same route as they would in case of full-mesh. This approach however places additional burden on the control plane." First of I do not anticipate having to send more than two paths for almost = all cases. Secondly this is applied on a per prefix basis so there is not a= doubling of routing state.. So I do not think this concern is warranted.. = There are tools and guidelines for setting the number of paths see http://t= ools.ietf.org/html/draft-ietf-idr-add-paths-guidelines-02 for a complete de= scription which examines a number of use cases.. "For example, if next-hop information itself has been learned via BGP then simple SPF run on link-state database won't be sufficient to obtain cost information." The AIGP metric is used to carry the "cost" to the NH of the path.. This dr= aft was developed to address the exact issue of carrying NH info in bgp and= losing the notion of an accumulated cost.. Why is that not sufficient?=20 I also do not see how you del with this except for the creation of a table = of NHs and associated costs.. But how is that created? Does the new AFI/SAF= I accumulate costs across multiple IPG domains? I would like to understand what scenarios require this solution above and b= eyond a correct addpaths setting and/or AIGP.. 2. Next-Hop Information Base " NHIB can be populated from various sources both static and dynamic. This document focuses on populating NHIB using BGP. However it is possible that protocols other than BGP could be also used to populate NHIB." This is a bit vague.. if you are learning NHs in BGP without the accumulate= d cost then the only way to populate is to statically define costs to NHs..= this seems burdensome and is not easily change to reflect the dynamic of c= ost due to maintenance or failure.. putting aside the difficulty in creatin= g and maintaining this NHIB it seems that it cannot respond to changes in t= he topology.. 3. BGP BEST PATH SELECTION MODIFICATION Lots of chatter about the sanctity of the BGP Best path selection.. Have yo= u spoken to folks who seem to be vehemently opposed? 4. A general note about introducing AFI/SAFIs.. This is always not trivial as = it introduces scale, control plane complexity and vulnerability.. What happ= ens if the AFI/SAFI becomes compromised? It would be good if you could desc= ribe that here.. My assumption would be that you would fall back to igp cos= t? In summary, I do not understand how addpaths and AIGP do not solve this pro= blem.=20 -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Anton= Elita Sent: Wednesday, November 23, 2011 11:05 AM To: idr@ietf.org List Subject: Re: [Idr] Adoption of draft-varlashkin-bgp-nh-cost-02 as IDR WG do= cument? Support --=20 Anton Elita Tinet On Wed, Nov 16, 2011 at 10:06 AM, John Scudder wrote: > Folks, > > We have received a request from the authors to adopt draft-varlashkin-bgp= -nh-cost-02 as an IDR WG document. =A0Please send your comments to the list= . =A0The deadline for comments is December 5, 2011 at noon EST. > > Thanks, > > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From robert@raszuk.net Sat Nov 26 09:21:28 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF9021F8B8D for ; Sat, 26 Nov 2011 09:21:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adFp61sltdg1 for ; Sat, 26 Nov 2011 09:21:27 -0800 (PST) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 0C04521F8B80 for ; Sat, 26 Nov 2011 09:21:26 -0800 (PST) Received: (qmail 22285 invoked by uid 399); 26 Nov 2011 17:21:25 -0000 Received: from unknown (HELO ?192.168.1.57?) (83.9.122.97) by mail1310.opentransfer.com with ESMTP; 26 Nov 2011 17:21:25 -0000 X-Originating-IP: 83.9.122.97 Message-ID: <4ED12015.6060002@raszuk.net> Date: Sat, 26 Nov 2011 18:21:25 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "UTTARO, JAMES" References: <7B61DC70-08D9-46C7-8C15-5DD339C61C2D@juniper.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-varlashkin-bgp-nh-cost-02 as IDR WG document? 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: Sat, 26 Nov 2011 17:21:28 -0000 James, > First of I do not anticipate having to send more than two paths for > almost all cases. Great that you said this. As tier 1 I have 25 paths for each b_net. I have a path for each of my peering point with other tier1s or tier2s How do I figure which ones are optimal for the client or group of clients located in the same POP from the route reflector pov ? With add-paths or without add-paths the problem to be solved remains exactly the same. Problem goes away only in the following cases: - if you have only 1 path for all prefixes, - if you have only 2 paths max for all prefixes, - if you decide to send _all_ my domain external paths to all clients .. in the above case 25 paths ! Sorry ... bad idea. > The AIGP metric is used to carry the "cost" to the NH of the path.. AIGP is completely irrelevant here. In fact it is a pretty poor design choise to choose a path for all clients based on AIGP metric or IGP metric from the point of view of control plane route reflector in a given AS. Keep in mind that AIGP is relevant only when number of ASes are under the same administration. Not that common case in the Internet :)Usually folks do know how to run single AS globally without any issues. The problem which needs to be solved is to provide information to the RR in order for RR client to be able to receive optimal paths - optimal for example to follow hot potato routing requirements in a given AS. If one would follow AIGP metric some control plane RR clients may clearly get not optimal exit paths from the AS they reside point of view. Best, R. > Ilya, > > Apologies for not responding sooner.. I do have some questions in re > the draft.. > > > 1. Motivation > > "ADDPATH solves this problem by letting route-reflector to advertise > multiple paths for given prefix. If number of advertised paths > sufficiently big, route-reflector clients can choose same route as > they would in case of full-mesh. This approach however places > additional burden on the control plane." > > First of I do not anticipate having to send more than two paths for > almost all cases. Secondly this is applied on a per prefix basis so > there is not a doubling of routing state.. So I do not think this > concern is warranted.. There are tools and guidelines for setting the > number of paths see > http://tools.ietf.org/html/draft-ietf-idr-add-paths-guidelines-02 for > a complete description which examines a number of use cases.. > > "For example, if next-hop information itself has been learned via BGP > then simple SPF run on link-state database won't be sufficient to > obtain cost information." > > The AIGP metric is used to carry the "cost" to the NH of the path.. > This draft was developed to address the exact issue of carrying NH > info in bgp and losing the notion of an accumulated cost.. Why is > that not sufficient? > > I also do not see how you del with this except for the creation of a > table of NHs and associated costs.. But how is that created? Does the > new AFI/SAFI accumulate costs across multiple IPG domains? > > I would like to understand what scenarios require this solution above > and beyond a correct addpaths setting and/or AIGP.. > > 2. Next-Hop Information Base > > " NHIB can be populated from various sources both static and > dynamic. This document focuses on populating NHIB using BGP. However > it is possible that protocols other than BGP could be also used to > populate NHIB." > > This is a bit vague.. if you are learning NHs in BGP without the > accumulated cost then the only way to populate is to statically > define costs to NHs.. this seems burdensome and is not easily change > to reflect the dynamic of cost due to maintenance or failure.. > putting aside the difficulty in creating and maintaining this NHIB it > seems that it cannot respond to changes in the topology.. > > 3. BGP BEST PATH SELECTION MODIFICATION > > Lots of chatter about the sanctity of the BGP Best path selection.. > Have you spoken to folks who seem to be vehemently opposed? > > 4. > > A general note about introducing AFI/SAFIs.. This is always not > trivial as it introduces scale, control plane complexity and > vulnerability.. What happens if the AFI/SAFI becomes compromised? It > would be good if you could describe that here.. My assumption would > be that you would fall back to igp cost? > > In summary, I do not understand how addpaths and AIGP do not solve > this problem. > > > > -----Original Message----- From: idr-bounces@ietf.org > [mailto:idr-bounces@ietf.org] On Behalf Of Anton Elita Sent: > Wednesday, November 23, 2011 11:05 AM To: idr@ietf.org List Subject: > Re: [Idr] Adoption of draft-varlashkin-bgp-nh-cost-02 as IDR WG > document? > > Support > From ju1738@att.com Sat Nov 26 17:21:33 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC3B21F8880 for ; Sat, 26 Nov 2011 17:21:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.946 X-Spam-Level: X-Spam-Status: No, score=-105.946 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPpcGk+ULg+n for ; Sat, 26 Nov 2011 17:21:33 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id D6E3F21F87D9 for ; Sat, 26 Nov 2011 17:21:32 -0800 (PST) X-Env-Sender: ju1738@att.com X-Msg-Ref: server-12.tower-119.messagelabs.com!1322356888!2966037!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1332 invoked from network); 27 Nov 2011 01:21:28 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-12.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Nov 2011 01:21:28 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pAR1Lu12017846; Sat, 26 Nov 2011 20:21:57 -0500 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pAR1LoPd017798 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 26 Nov 2011 20:21:50 -0500 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([169.254.1.53]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.01.0339.001; Sat, 26 Nov 2011 20:21:20 -0500 From: "UTTARO, JAMES" To: "'robert@raszuk.net'" Thread-Topic: [Idr] Adoption of draft-varlashkin-bgp-nh-cost-02 as IDR WG document? Thread-Index: AcykPwG7jl6Kwgf+R0CL/omsorSMmQF5IPuAAIh6m/AAERL1gAAFMLfg Date: Sun, 27 Nov 2011 01:21:20 +0000 Message-ID: References: <7B61DC70-08D9-46C7-8C15-5DD339C61C2D@juniper.net> <4ED12015.6060002@raszuk.net> In-Reply-To: <4ED12015.6060002@raszuk.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.197.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-varlashkin-bgp-nh-cost-02 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: Sun, 27 Nov 2011 01:21:34 -0000 Comments In-Line.. Jim Uttaro -----Original Message----- From: Robert Raszuk [mailto:robert@raszuk.net]=20 Sent: Saturday, November 26, 2011 12:21 PM To: UTTARO, JAMES Cc: 'Anton Elita'; idr@ietf.org List Subject: Re: [Idr] Adoption of draft-varlashkin-bgp-nh-cost-02 as IDR WG do= cument? James, > First of I do not anticipate having to send more than two paths for > almost all cases. Great that you said this. As tier 1 I have 25 paths for each b_net. I=20 have a path for each of my peering point with other tier1s or tier2s How do I figure which ones are optimal for the client or group of=20 clients located in the same POP from the route reflector pov ? [Jim U>] I believe that there should be some determination made as to what = to flood.. I wasn't actually thinking of it from a topology sense but from = a perspective of which prefixes should get the enhanced service definition = above and beyond a traditional internet definition..=20 [Jim U>] Hmm I guess I am not understanding this. I am under the impression= that path P1 is learned from let's say 25 different peering points.. first= let's examine let's examine P1 from Peer A and Peer B where these two peer= s are close together.. The RR serving these two POPs would forward either P= 1:NH=3DA and P1:NH=3DB to RR1 based on its local BGP Table that has been st= atically configured (Ouch) .. If RR1 also learns P1:NH=3DC then you want th= e RR1 to evaluate the BGP "Cost" and select the NH with the best IGP cost..= is that right? Ok So RR1 has statically accumulated the cost from itself t= o RR and to the egress peer? Is it really your intention to create unique = tables at every point in the network which would essentially be an IGP grap= h of the topology using the local node as the root.. That is an operational= nightmare and probably a catastrophe.. Again as I stated before there is n= o way to adapt to a changing topology due to failure or maintenance.. can y= ou address that..=20 It is not clear how sub-optimal the selection of P1 with addpaths=3D2 would= be. Certainly there are other metrics i.e AS-PATH length which will immedi= ately paths Again to our ex.. with addpaths=3D2 in the RR topology you woul= d always send the two best IGP paths based on cost.. If you do this at ever= y point how sub-optimal could it be? Have you done an analysis of this... = That would be a good addition to the draft as it would clear up any confusi= on in terms of addpaths applicability and the need for this draft.. With add-paths or without add-paths the problem to be solved remains=20 exactly the same. Problem goes away only in the following cases: - if you have only 1 path for all prefixes, - if you have only 2 paths max for all prefixes, - if you decide to send _all_ my domain external paths to all clients ..=20 in the above case 25 paths ! Sorry ... bad idea. > The AIGP metric is used to carry the "cost" to the NH of the path.. AIGP is completely irrelevant here. In fact it is a pretty poor design=20 choise to choose a path for all clients based on AIGP metric or IGP=20 metric from the point of view of control plane route reflector in a=20 given AS. Keep in mind that AIGP is relevant only when number of ASes are under=20 the same administration. Not that common case in the Internet :)Usually=20 folks do know how to run single AS globally without any issues. The problem which needs to be solved is to provide information to the RR=20 in order for RR client to be able to receive optimal paths - optimal for=20 example to follow hot potato routing requirements in a given AS. If one would follow AIGP metric some control plane RR clients may=20 clearly get not optimal exit paths from the AS they reside point of view. [Jim U>] I thought you wanted an RR-client ( PE ) to select the best egress= NH for a given path..Assuming a BGP 3107 design with AIGP ( pseudo IGP ) Best, R. > Ilya, > > Apologies for not responding sooner.. I do have some questions in re > the draft.. > > > 1. Motivation > > "ADDPATH solves this problem by letting route-reflector to advertise > multiple paths for given prefix. If number of advertised paths > sufficiently big, route-reflector clients can choose same route as > they would in case of full-mesh. This approach however places > additional burden on the control plane." > > First of I do not anticipate having to send more than two paths for > almost all cases. Secondly this is applied on a per prefix basis so > there is not a doubling of routing state.. So I do not think this > concern is warranted.. There are tools and guidelines for setting the > number of paths see > http://tools.ietf.org/html/draft-ietf-idr-add-paths-guidelines-02 for > a complete description which examines a number of use cases.. > > "For example, if next-hop information itself has been learned via BGP > then simple SPF run on link-state database won't be sufficient to > obtain cost information." > > The AIGP metric is used to carry the "cost" to the NH of the path.. > This draft was developed to address the exact issue of carrying NH > info in bgp and losing the notion of an accumulated cost.. Why is > that not sufficient? > > I also do not see how you del with this except for the creation of a > table of NHs and associated costs.. But how is that created? Does the > new AFI/SAFI accumulate costs across multiple IPG domains? > > I would like to understand what scenarios require this solution above > and beyond a correct addpaths setting and/or AIGP.. > > 2. Next-Hop Information Base > > " NHIB can be populated from various sources both static and > dynamic. This document focuses on populating NHIB using BGP. However > it is possible that protocols other than BGP could be also used to > populate NHIB." > > This is a bit vague.. if you are learning NHs in BGP without the > accumulated cost then the only way to populate is to statically > define costs to NHs.. this seems burdensome and is not easily change > to reflect the dynamic of cost due to maintenance or failure.. > putting aside the difficulty in creating and maintaining this NHIB it > seems that it cannot respond to changes in the topology.. > > 3. BGP BEST PATH SELECTION MODIFICATION > > Lots of chatter about the sanctity of the BGP Best path selection.. > Have you spoken to folks who seem to be vehemently opposed? > > 4. > > A general note about introducing AFI/SAFIs.. This is always not > trivial as it introduces scale, control plane complexity and > vulnerability.. What happens if the AFI/SAFI becomes compromised? It > would be good if you could describe that here.. My assumption would > be that you would fall back to igp cost? > > In summary, I do not understand how addpaths and AIGP do not solve > this problem. > > > > -----Original Message----- From: idr-bounces@ietf.org > [mailto:idr-bounces@ietf.org] On Behalf Of Anton Elita Sent: > Wednesday, November 23, 2011 11:05 AM To: idr@ietf.org List Subject: > Re: [Idr] Adoption of draft-varlashkin-bgp-nh-cost-02 as IDR WG > document? > > Support > From robert@raszuk.net Sun Nov 27 07:57:14 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2FFB21F8B62 for ; Sun, 27 Nov 2011 07:57:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.006 X-Spam-Level: X-Spam-Status: No, score=-2.006 tagged_above=-999 required=5 tests=[AWL=-0.507, BAYES_00=-2.599, GB_PAYLESS=0.5, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HZJjur7MJT8 for ; Sun, 27 Nov 2011 07:57:13 -0800 (PST) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id E27A821F8B2D for ; Sun, 27 Nov 2011 07:57:12 -0800 (PST) Received: (qmail 25951 invoked by uid 399); 27 Nov 2011 15:57:12 -0000 Received: from unknown (HELO ?192.168.1.91?) (83.31.148.193) by mail1310.opentransfer.com with ESMTP; 27 Nov 2011 15:57:12 -0000 X-Originating-IP: 83.31.148.193 Message-ID: <4ED25DD9.8050209@raszuk.net> Date: Sun, 27 Nov 2011 16:57:13 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "UTTARO, JAMES" References: <7B61DC70-08D9-46C7-8C15-5DD339C61C2D@juniper.net> <4ED12015.6060002@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-varlashkin-bgp-nh-cost-02 as IDR WG document? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2011 15:57:14 -0000 > Great that you said this. As tier 1 I have 25 paths for each b_net. > I have a path for each of my peering point with other tier1s or > tier2s > > How do I figure which ones are optimal for the client or group of > clients located in the same POP from the route reflector pov ? > [Jim U>] I believe that there should be some determination made as to > what to flood.. I wasn't actually thinking of it from a topology > sense but from a perspective of which prefixes should get the > enhanced service definition above and beyond a traditional internet > definition.. Since we are talking about Internet routing what is your definition of "enhanced service definition" vs "traditional internet definition" ? Are you trying to say that those who pay less do not deserve closest exit ? In other words if I am a customer and I did not pay premium my packets will end up traveling around ATT's autonomous system miles before they exit towards the destination ? I think most providers today do value sending customer packets to their closest exit point from the point of view of PE which is receiving those packets rather then from the point of view of some control plane RR sitting somewhere in the middle or maybe on the other side of their AS. That's why for Internet routing RRs are still in the data path most often at the core to pop boundaries and POPs are fully meshed. > [Jim U>] Hmm I guess I am not understanding this. I am > under the impression that path P1 is learned from let's say 25 > different peering points.. first let's examine let's examine P1 from > Peer A and Peer B where these two peers are close together.. The RR > serving these two POPs would forward either P1:NH=A and P1:NH=B to > RR1 based on its local BGP Table that has been statically configured > (Ouch) .. Ouch x 2 :) 1. If you read the IDR WG draft RRs are fully meshed and RRs exchange all externals paths. 2. The draft which is the subject of this thread or just IGP itself avoid to have any static configuration on RRs. > If RR1 also learns P1:NH=C then you want the RR1 to > evaluate the BGP "Cost" and select the NH with the best IGP cost.. is > that right? Ok So RR1 has statically accumulated the cost from itself > to RR and to the egress peer? Is it really your intention to create > unique tables at every point in the network which would essentially > be an IGP graph of the topology using the local node as the root.. > That is an operational nightmare and probably a catastrophe.. LOL ... therefor I guess you will never deploy LFA as this would be a catastrophe too. > Again > as I stated before there is no way to adapt to a changing topology > due to failure or maintenance.. can you address that.. There is no static configuration involved at all so adjusting to topology changes is automatic and build in. For both auto IGP calculation as well as for NH-SAFI there are thresholds of information distribution. > It is not clear how sub-optimal the selection of P1 with addpaths=2 > would be. Certainly there are other metrics i.e AS-PATH length which > will immediately paths Again to our ex.. with addpaths=2 in the RR > topology you would always send the two best IGP paths based on cost.. That would be the cost from the point of view of RR. That is the problem. If you distribute RRs to be in each POP .. there is no problem. However more and more operators are moving towards control plane RRs .. even control plane RR in the virtual environments. > If you do this at every point how sub-optimal could it be? Have you > done an analysis of this... That would be a good addition to the > draft as it would clear up any confusion in terms of addpaths > applicability and the need for this draft.. See above. Analysis is obvious. > view. [Jim U>] I thought you wanted an RR-client ( PE ) to select the > best egress NH for a given path..Assuming a BGP 3107 design with AIGP > ( pseudo IGP ) AIGP can still be used but applied as additive metric from the point of view of the client not the RR. Best, R. From ilya@nobulus.com Mon Nov 28 03:28:36 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3463321F8CC3 for ; Mon, 28 Nov 2011 03:28:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfcuc-c6-BYA for ; Mon, 28 Nov 2011 03:28:35 -0800 (PST) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by ietfa.amsl.com (Postfix) with ESMTP id 0437C21F8CBF for ; Mon, 28 Nov 2011 03:28:33 -0800 (PST) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id 584D817128; Mon, 28 Nov 2011 12:28:30 +0100 (CET) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id paiA-7gIotOk; Mon, 28 Nov 2011 12:28:27 +0100 (CET) Received: from hnivarlas1 (unknown [IPv6:2001:6f8:892:6f8:dd55:57ed:7072:e255]) by nobulus.com (Postfix) with ESMTPA id 3A2951717E; Mon, 28 Nov 2011 12:28:25 +0100 (CET) Message-ID: <25F165FDE7154695971701696ED4F771@hnivarlas1> From: "iLya" To: "UTTARO, JAMES" , References: <7B61DC70-08D9-46C7-8C15-5DD339C61C2D@juniper.net><4ED12015.6060002@raszuk.net> In-Reply-To: Date: Mon, 28 Nov 2011 12:28:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 Cc: idr@ietf.org Subject: Re: [Idr] Adoption of draft-varlashkin-bgp-nh-cost-02 as IDRWG 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: Mon, 28 Nov 2011 11:28:36 -0000 Jim, thanks for your review. Before I go into addressing your points, please bear in mind that NH SAFI is not a competing but complementing technology to ADD-PATH. Neither of these two can solve certain problems alone, but together they provide comprehensive toolkit for wide range of scenarios. -------------------------------------------------- > > First of I do not anticipate having to send more than two paths for > > almost all cases. > To amplify Robert's response - I also have widely distributed set of ASBR's that peer with foreign networks in Asia, Europe and America. Currently they're fully meshed because ADD-PATH alone would require me either to deploy almost as many RR's as I have ASBR's today or to send 4 to 8 various path's per prefix, else I might endup sending traffic from Hong Kong to West Coast US via Europe or from Netherlands to Germany via East Coast US. With NH SAFI _plus_ ADD-PATH solution for optimum redundant routeing is to obtain next-hop cost from each RR-client via NH SAFI and to send best and next-best route using ADD-PATH. > [Jim U>] I believe that there should be some determination made as to what > to flood.. I wasn't actually thinking of it from a topology sense but from > a perspective of which prefixes should get the enhanced service definition > above and beyond a traditional internet definition.. Not sure what "enhanced" means in this context, but I as service provider do want to send any traffic to an optimum exit points regardless how much customer pays because such traffic management allows me better resource utilisation. And with that in mind I'd like my route reflectors to advertise (flood) what's better from each RR-client's perspective. > [Jim U>] Hmm I guess I am not understanding this. I am under the > impression that path P1 is learned from let's say 25 different peering > points.. first let's examine let's examine P1 from Peer A and Peer B where > these two peers are close together.. The RR serving these two POPs would > forward either P1:NH=A and P1:NH=B to RR1 based on its local BGP Table > that has been statically configured (Ouch) .. If RR1 also learns P1:NH=C > then you want the RR1 to evaluate the BGP "Cost" and Where does static configuration come from? NH SAFI allows RR to dynamically obtain cost info from each of its clients, and this information may (though doesn't have to) be updated when network topology changes. Also note that RR learns new info only when client something new to tell, which is normally rather infrequent. It's important to realise that RR does not query RR-c before sending each prefix and does not wait for client reply (it starts using client's perspective for best path selection when it has collected all necessary info), respectively client does not need to wait for request from RR but can guesstimate which /32 or /128 prefixes in its routeing table are potential exit points and send that info to RR. > select the NH with the best IGP cost.. is that right? Ok So RR1 has > statically accumulated the cost from itself to RR and to the egress peer? > Is it really your intention to create unique tables at every point in the > network which would essentially be an IGP graph of the topology using the > local node as the root.. That is an operational nightmare and probably a > catastrophe.. Again as I stated before there is no way to adapt to a > changing topology due to failure or maintenance.. can you address that.. > Since RR-c can send info to RR at any time, clearly NH SAFI has built-in mechanism to adapt to changing topology. Yes, RR needs to maintain per-client cost-to-NH tables, but even for large networks number of entries in such tables is very small (<1000 for huge networks, usually less than 50 for tier-1 class networks). On the other hand number of various best path's is even smaller because you'll most likely have groups of clients that share same preference for particular next-hops (though their absolute costs to such NH may vary). Considering that NH SAFI info is stored only in RAM but not in TCAM, and even software-based platforms today have plenty of RAM available, I do not foresee NH SAFI to have significant impact on RR capacity. > It is not clear how sub-optimal the selection of P1 with addpaths=2 would > be. Certainly there are other metrics i.e AS-PATH length which will > immediately paths Again to our ex.. with addpaths=2 in the RR topology you > would always send the two best IGP paths based on cost.. If you do this at > every point how sub-optimal could it be? Have you done an analysis of > this... That would be a good addition to the draft as it would clear up > any confusion in terms of addpaths applicability and the need for this > draft.. > If I peer with ISP1 in 10 locations across the globe, I can have up 10 potential next-hops. With addpath=2 I get two best paths for RR-c to choose from. If one my RR is located in Amsterdam and another in LA, an RR-c in Switzerland will get two best paths - one via LA and one via Amsterdam, but path to AMS goes via Germany where traffic could exit. With NH SAFI added RR-c in Switzerland can tell RR that Frankfurt and Amsterdam are closest so both AMS and LA route reflectors will furnish Swiss client again with two paths (using ADD-PATH) but this time via Frankfurt and via Amsterdam. > > The AIGP metric is used to carry the "cost" to the NH of the path.. > Suppose AIGP info has arrived to RR. Now RR knows in fine details what's cost to Prefix A, but sadly that's still from RR perspective. From RR-c perspective AIGP has not added any improvement. > [Jim U>] I thought you wanted an RR-client ( PE ) to select the best > egress NH for a given path..Assuming a BGP 3107 design with AIGP ( pseudo > IGP ) > Note that best egress NH is not only for a given path, but for a given path from given client perspective. In situation where you have comprehensive number of peerings you're still back into square one regarding selection of best egress point. I hope I have addressed your concerns and we could progress with the draft adoption. Kind regards, iLya From internet-drafts@ietf.org Tue Nov 29 12:27:16 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873481F0CB9; Tue, 29 Nov 2011 12:27:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nwp-WiFrW+Y; Tue, 29 Nov 2011 12:27:12 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22EB71F0C88; Tue, 29 Nov 2011 12:27:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64 Message-ID: <20111129202712.749.99626.idtracker@ietfa.amsl.com> Date: Tue, 29 Nov 2011 12:27:12 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-as0-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, 29 Nov 2011 20:27:16 -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 : Codification of AS 0 processing. Author(s) : Warren Kumari Randy Bush Heather Schiller Filename : draft-ietf-idr-as0-00.txt Pages : 5 Date : 2011-11-29 This document proscribes the use of AS 0 in BGP OPEN and AS_PATH / AS4_PATH BGP attribute. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-as0-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-as0-00.txt From internet-drafts@ietf.org Tue Nov 29 12:28:01 2011 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 277251F0CCD; Tue, 29 Nov 2011 12:28:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5IWtgUAXdXr; Tue, 29 Nov 2011 12:27:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66A731F0CC6; Tue, 29 Nov 2011 12:27:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64 Message-ID: <20111129202759.1130.30160.idtracker@ietfa.amsl.com> Date: Tue, 29 Nov 2011 12:27:59 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-custom-decision-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, 29 Nov 2011 20:28:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of= the IETF. Title : BGP Custom Decision Process Author(s) : Alvaro Retana Russ White Filename : draft-ietf-idr-custom-decision-00.txt Pages : 8 Date : 2011-11-21 The BGP specification defines a Decision Process for installation of routes into the Loc-RIB. This process takes into account an extensive series of path attributes, which can be manipulated to indicate preference for specific paths. It is cumbersome (if at all possible) for the end user to define policies that will select, after partial comparison, a path based on subjective local (domain and/or node) criteria. This document defines a new Extended Community, called the Cost Community, which may be used in tie breaking during the best path selection process. The end result is a local custom decision process. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-custom-decision-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-custom-decision-00.txt