From daniel@olddog.co.uk Wed Jan 1 15:02:04 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9221ADA74 for ; Wed, 1 Jan 2014 15:02:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJ22dME-YXpN for ; Wed, 1 Jan 2014 15:02:01 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 31ED51ADF2F for ; Wed, 1 Jan 2014 15:02:01 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s01N1rGS018211 for ; Wed, 1 Jan 2014 23:01:53 GMT Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s01N1qIZ018172 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 1 Jan 2014 23:01:52 GMT From: "Daniel King" To: Date: Wed, 1 Jan 2014 23:01:47 -0000 Message-ID: <012601cf0745$733bf200$59b3d600$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0127_01CF0745.733CDC60" X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac8HRTBjAN2bhM9QQpSxQsDJk5pbmA== Content-Language: en-gb X-TM-AS-MML: No Subject: [Idr] PCE Text within draft-wu-idr-te-pm-bgp-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jan 2014 23:02:04 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0127_01CF0745.733CDC60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Authors, Useful I-D, and nice to see H-PCE Architecture (RFC6805) being discussed in use cases. My comment is a suggested text update for Section 3.1 (MPLS-TE with PCE): >> For inter-AS path computation the Hierarchical PCE (H-PCE) [RFC6805] may be used to compute the optimal sequence of domains. Within the H-PCE architecture, the child PCE communicates domain connectivity information to the parent PCE, and the parent PCE will use this information to compute a multi-domain path based on the optimal TE links between domains for the end-to-end path. The following figure demonstrates how a child PCE may obtain TE performance information beyond that contained in the LINK_STATE attributes [I.D-ietf-idr-ls-distribution] using the mechanism described in this document. << Also an FYI, we (PCE WG) adopted the H-PCE extensions document (http://tools.ietf.org/html/draft-ietf-pce-hierarchy-extensions). So if you are discussing configuration examples, you may also want to reference this document as well. Br, Dan. ------=_NextPart_000_0127_01CF0745.733CDC60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Authors,


Useful I-D, and nice to see H-PCE Architecture = (RFC6805) being discussed in use cases.

 

My comment = is a suggested text update for Section 3.1 (MPLS-TE with = PCE):

 

>> 

For = inter-AS path computation the Hierarchical PCE (H-PCE) [RFC6805] may be = used to compute the optimal sequence of domains. Within the H-PCE = architecture, the child PCE communicates domain connectivity information = to the parent PCE, and the parent PCE will use this information to = compute a multi-domain path based on the optimal TE links between = domains for the end-to-end path.

 

The = following figure demonstrates how a child PCE may obtain TE performance = information beyond that contained in the LINK_STATE attributes = [I.D-ietf-idr-ls-distribution] using the mechanism described in this = document.

<< 

 

Also an FYI, = we (PCE WG) adopted the H-PCE extensions document (h= ttp://tools.ietf.org/html/draft-ietf-pce-hierarchy-extensions). So = if you are discussing configuration examples, you may also want to = reference this document as well.  

 

Br, Dan. =

------=_NextPart_000_0127_01CF0745.733CDC60-- From daniel@olddog.co.uk Wed Jan 1 15:05:24 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD9BA1ADF39 for ; Wed, 1 Jan 2014 15:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hph0wjivfKy7 for ; Wed, 1 Jan 2014 15:05:23 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 360701ADF2F for ; Wed, 1 Jan 2014 15:05:23 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s01N5D9H026431 for ; Wed, 1 Jan 2014 23:05:13 GMT Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s01N5BDC026410 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 1 Jan 2014 23:05:12 GMT From: "Daniel King" To: Date: Wed, 1 Jan 2014 23:05:07 -0000 Message-ID: <013001cf0745$ea451ed0$becf5c70$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac8HRZxMfOr77+WERgilq/lJh6Rj/A== Content-Language: en-gb Subject: Re: [Idr] draft-wu-idr-te-pm-bgp-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jan 2014 23:05:25 -0000 /Support Br, Dan. >idr people > >This is to start a WG adoption call for this draft. It will end on 1/6/13. > >http://datatracker.ietf.org/doc/draft-wu-idr-te-pm-bgp/ > >BGP attribute for North-Bound Distribution of Traffic Engineering (TE) performance Metrics > >Two implementations in progress so feedback on this draft is also welcomed by the authors. > >Sue and John From internet-drafts@ietf.org Thu Jan 2 12:21:54 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40BA11ADF59; Thu, 2 Jan 2014 12:21:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSJdO97fKf9Y; Thu, 2 Jan 2014 12:21:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A07B51A1521; Thu, 2 Jan 2014 12:21:51 -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: 4.90 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140102202151.12743.64761.idtracker@ietfa.amsl.com> Date: Thu, 02 Jan 2014 12:21:51 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-optimal-route-reflection-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2014 20:21:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : BGP Optimal Route Reflection (BGP-ORR) Authors : Robert Raszuk Christian Cassar Erik Aman Bruno Decraene Stephane Litkowski Filename : draft-ietf-idr-bgp-optimal-route-reflection-06.txt Pages : 22 Date : 2014-01-02 Abstract: [RFC4456] asserts that, because the Interior Gateway Protocol (IGP) cost to a given point in the network will vary across routers, "the route reflection approach may not yield the same route selection result as that of the full IBGP mesh approach." One practical implication of this assertion is that the deployment of route reflection may thwart the ability to achieve hot potato routing. Hot potato routing attempts to direct traffic to the closest AS egress point in cases where no higher priority policy dictates otherwise. As a consequence of the route reflection method, the choice of exit point for a route reflector and its clients will be the egress point closest to the route reflector - and not necessarily closest to the RR clients. Section 11 of [RFC4456] describes a deployment approach and a set of constraints which, if satsified, would result in the deployment of route reflection yielding the same results as the iBGP full mesh approach. Such a deployment approach would make route reflection compatible with the application of hot potato routing policy. As networks evolved to accommodate architectural requirements of new services, tunneled (LSP/IP tunneling) networks with centralized route reflectors became commonplace. This is one type of common deployment where it would be impractical to satisfy the constraints described in Section 11 of [RFC4456]. Yet, in such an environment, hot potato routing policy remains desirable. This document proposes two new solutions which can be deployed to facilitate the application of closest exit point policy centralized route reflection deployments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-optimal-route-reflectio= n/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-bgp-optimal-route-reflection-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-bgp-optimal-route-reflect= ion-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From xuxiaohu@huawei.com Thu Jan 2 19:45:14 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0523D1AD8F2 for ; Thu, 2 Jan 2014 19:45:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.212 X-Spam-Level: * X-Spam-Status: No, score=1.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kg86eg_f9Wgj for ; Thu, 2 Jan 2014 19:45:12 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AE6391AC4A7 for ; Thu, 2 Jan 2014 19:45:10 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCC17685; Fri, 03 Jan 2014 03:45:02 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 3 Jan 2014 03:44:43 +0000 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 3 Jan 2014 03:44:59 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Fri, 3 Jan 2014 11:44:52 +0800 From: Xuxiaohu To: Susan Hares , idr wg Thread-Topic: [Idr] draft-wu-idr-te-pm-bgp-03 Thread-Index: Ac8AAWPda2+yhgdLS6a8XtvBEudSUgINLUoA Date: Fri, 3 Jan 2014 03:44:51 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082412DB@NKGEML512-MBS.china.huawei.com> References: <000901cf0001$a240b270$e6c21750$@ndzh.com> In-Reply-To: <000901cf0001$a240b270$e6c21750$@ndzh.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082412DBNKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-wu-idr-te-pm-bgp@tools.ietf.org" Subject: [Idr] =?gb2312?b?tPC4tDogIGRyYWZ0LXd1LWlkci10ZS1wbS1iZ3AtMDM=?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 03:45:14 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082412DBNKGEML512MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 U3VwcG9ydC4NCg0KWGlhb2h1DQoNCreivP7IyzogSWRyIFttYWlsdG86aWRyLWJvdW5jZXNAaWV0 Zi5vcmddILT6se0gU3VzYW4gSGFyZXMNCreiy83KsbzkOiAyMDEzxOoxMtTCMjTI1SAxOjA5DQrK 1bz+yMs6IGlkciB3Zw0Ks63LzTogZHJhZnQtd3UtaWRyLXRlLXBtLWJncEB0b29scy5pZXRmLm9y Zw0K1vfM4jogW0lkcl0gZHJhZnQtd3UtaWRyLXRlLXBtLWJncC0wMw0KDQppZHIgcGVvcGxlDQoN ClRoaXMgaXMgdG8gc3RhcnQgYSBXRyBhZG9wdGlvbiBjYWxsIGZvciB0aGlzIGRyYWZ0LiBJdCB3 aWxsIGVuZCBvbiAxLzYvMTMuDQoNCmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtd3UtaWRyLXRlLXBtLWJncC8NCg0KQkdQIGF0dHJpYnV0ZSBmb3IgTm9ydGgtQm91bmQgRGlz dHJpYnV0aW9uIG9mIFRyYWZmaWMgRW5naW5lZXJpbmcgKFRFKSBwZXJmb3JtYW5jZSBNZXRyaWNz DQoNCg0KVHdvIGltcGxlbWVudGF0aW9ucyBpbiBwcm9ncmVzcyBzbyBmZWVkYmFjayBvbiB0aGlz IGRyYWZ0IGlzIGFsc28gd2VsY29tZWQgYnkgdGhlIGF1dGhvcnMuDQoNClN1ZSBhbmQgSm9obg0K DQo= --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082412DBNKGEML512MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Support.

 

Xiaohu

 

=B7=A2=BC=FE=C8=CB: Idr [mailto:idr-bounc= es@ietf.org] =B4=FA=B1=ED = Susan Hares
=B7=A2=CB=CD= =CA=B1=BC=E4: 2013=C4=EA12=D4=C2= 24=C8=D5 1:09
=CA=D5=BC=FE=C8=CB: idr wg
=B3=AD=CB=CD: draft-wu-idr-te-pm-bgp@tools.ietf.org
=D6=F7=CC=E2: [Idr] draft-wu-idr-te-pm-bgp-03

 

idr peopl= e

 

This is to start a WG adoption call for thi= s draft. It will end on 1/6/13. 

 

http://datatracker.ietf.org/doc/draft-wu-idr-te-pm= -bgp/

 

BG= P attribute for North-Bound Distribution of Traffic Engineering (TE) perfor= mance Metrics

 

 

Two implementations in progress so feedback= on this draft is also welcomed by the authors.

 

Sue and John

 <= /p>

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082412DBNKGEML512MBSchi_-- From dhruv.ietf@gmail.com Fri Jan 3 04:15:27 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6611ADF9A for ; Fri, 3 Jan 2014 04:15:27 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7H7ZJ8b5dsO1 for ; Fri, 3 Jan 2014 04:15:25 -0800 (PST) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 7F94E1ADF95 for ; Fri, 3 Jan 2014 04:15:25 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id as1so15825473iec.41 for ; Fri, 03 Jan 2014 04:15:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Lr77Kq5K+oN6XMBAy/Iy7+9UNuEgUKjxYQRSDnpL0VU=; b=gZDvfRzAsZ2Anf817B3/JbGrHVrCTz71YrJbIy2hDE71IlQseSQoWDTdfbYe8Afqs4 6htbxTZY0xNG+q1AzPqi7Kno79ss3kaY+KFVKWJvRrUmj3sMCZAtJS3Tsx9kIwFPcPB6 nlXkGWJu2Q5JyYw9ol3BzQLOeC4maQw7cV8cdxMXh3LwnbQZak3pmK24YaSbT/vdTE9K 56UHbINgOst9QmKYDqr/k5hX9ltFI2VtE50uZEDufL9jM2V7hClIDQtJ4Jev3ufuRrnW yfIyaQizKjYaiSVVs3PVeFcatt6MgMwbd+KnkCjc/ljZUqHIKOBcP4q6GUdhh9ZDKqB2 l+Tw== MIME-Version: 1.0 X-Received: by 10.42.65.73 with SMTP id k9mr7763846ici.44.1388751318151; Fri, 03 Jan 2014 04:15:18 -0800 (PST) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.30.98 with HTTP; Fri, 3 Jan 2014 04:15:18 -0800 (PST) In-Reply-To: <000901cf0001$a240b270$e6c21750$@ndzh.com> References: <000901cf0001$a240b270$e6c21750$@ndzh.com> Date: Fri, 3 Jan 2014 17:45:18 +0530 X-Google-Sender-Auth: yFQ2nb5Yrz0hGEWc9DQyvr5Cd5o Message-ID: From: Dhruv Dhody To: Susan Hares Content-Type: multipart/alternative; boundary=90e6ba3fcd17fff9c504ef0fdca3 Cc: idr wg , draft-wu-idr-te-pm-bgp@tools.ietf.org Subject: Re: [Idr] draft-wu-idr-te-pm-bgp-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 12:15:27 -0000 --90e6ba3fcd17fff9c504ef0fdca3 Content-Type: text/plain; charset=ISO-8859-1 Support! Regards, Dhruv On Mon, Dec 23, 2013 at 10:38 PM, Susan Hares wrote: > idr people > > > > This is to start a WG adoption call for this draft. It will end on > 1/6/13. > > > > http://datatracker.ietf.org/doc/draft-wu-idr-te-pm-bgp/ > > > > BGP attribute for North-Bound Distribution of Traffic Engineering (TE) > performance Metrics > > > > > > Two implementations in progress so feedback on this draft is also welcomed > by the authors. > > > > Sue and John > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --90e6ba3fcd17fff9c504ef0fdca3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Support!=A0

Regards,
Dhruv


On M= on, Dec 23, 2013 at 10:38 PM, Susan Hares <shares@ndzh.com> wr= ote:

idr people

=A0

This is to st= art a WG adoption call for this draft. It will end on 1/6/13.=A0 =

=A0

ht= tp://datatracker.ietf.org/doc/draft-wu-idr-te-pm-bgp/

=A0

BGP attribute for North-Bound Distribution of Traffic Eng= ineering (TE) performance Metrics

=A0

=A0=

Two implementations in progress so feedback on this draft = is also welcomed by the authors.

=A0

Sue and John

=A0


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


--90e6ba3fcd17fff9c504ef0fdca3-- From jdrake@juniper.net Fri Jan 3 06:53:41 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33E961ADFE1 for ; Fri, 3 Jan 2014 06:53:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6pjpG828C2K for ; Fri, 3 Jan 2014 06:53:39 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id C56951ADFD7 for ; Fri, 3 Jan 2014 06:53:38 -0800 (PST) Received: from mail208-va3-R.bigfish.com (10.7.14.244) by VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id 14.1.225.22; Fri, 3 Jan 2014 14:53:31 +0000 Received: from mail208-va3 (localhost [127.0.0.1]) by mail208-va3-R.bigfish.com (Postfix) with ESMTP id F321B18012D; Fri, 3 Jan 2014 14:53:30 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: VPS-19(zz9371Ic85fhzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1de097h186068hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h20f0h2216h22d0h2336h9a9j1155h) Received-SPF: pass (mail208-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(189002)(377454003)(199002)(66066001)(81816001)(87936001)(80022001)(59766001)(85852003)(65816001)(80976001)(76576001)(77982001)(54316002)(47446002)(46102001)(76796001)(2656002)(76786001)(16236675002)(31966008)(56816005)(87266001)(83072002)(90146001)(56776001)(69226001)(81686001)(19609705001)(83322001)(74662001)(49866001)(79102001)(53806001)(50986001)(74706001)(33646001)(74876001)(4396001)(54356001)(74502001)(85306002)(51856001)(47976001)(81342001)(74316001)(19580405001)(15975445006)(19580395003)(47736001)(19300405004)(81542001)(63696002)(76482001)(74366001)(15202345003)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB564; H:BLUPR05MB562.namprd05.prod.outlook.com; CLIP:66.129.241.17; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail208-va3 (localhost.localdomain [127.0.0.1]) by mail208-va3 (MessageSwitch) id 1388760808853427_27395; Fri, 3 Jan 2014 14:53:28 +0000 (UTC) Received: from VA3EHSMHS018.bigfish.com (unknown [10.7.14.226]) by mail208-va3.bigfish.com (Postfix) with ESMTP id CD47A500047; Fri, 3 Jan 2014 14:53:28 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS018.bigfish.com (10.7.99.28) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 3 Jan 2014 14:53:22 +0000 Received: from BLUPR05MB564.namprd05.prod.outlook.com (10.141.202.150) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.395.1; Fri, 3 Jan 2014 14:53:22 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BLUPR05MB564.namprd05.prod.outlook.com (10.141.202.150) with Microsoft SMTP Server (TLS) id 15.0.842.7; Fri, 3 Jan 2014 14:53:20 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) by BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) with mapi id 15.00.0842.003; Fri, 3 Jan 2014 14:53:21 +0000 From: John E Drake To: Susan Hares , idr wg Thread-Topic: [Idr] draft-wu-idr-te-pm-bgp-03 Thread-Index: Ac8AAWPdssnbKOftQE2H2DzRobdO/QIkiJog Date: Fri, 3 Jan 2014 14:53:20 +0000 Message-ID: <728f0b441bce47efa8a34890871cf075@BLUPR05MB562.namprd05.prod.outlook.com> References: <000901cf0001$a240b270$e6c21750$@ndzh.com> In-Reply-To: <000901cf0001$a240b270$e6c21750$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.17] x-forefront-prvs: 00808B16F3 Content-Type: multipart/alternative; boundary="_000_728f0b441bce47efa8a34890871cf075BLUPR05MB562namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "draft-wu-idr-te-pm-bgp@tools.ietf.org" Subject: Re: [Idr] draft-wu-idr-te-pm-bgp-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 14:53:41 -0000 --_000_728f0b441bce47efa8a34890871cf075BLUPR05MB562namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support Yours Irrespectively, John From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, December 23, 2013 9:09 AM To: idr wg Cc: draft-wu-idr-te-pm-bgp@tools.ietf.org Subject: [Idr] draft-wu-idr-te-pm-bgp-03 idr people This is to start a WG adoption call for this draft. It will end on 1/6/13. http://datatracker.ietf.org/doc/draft-wu-idr-te-pm-bgp/ BGP attribute for North-Bound Distribution of Traffic Engineering (TE) perf= ormance Metrics Two implementations in progress so feedback on this draft is also welcomed = by the authors. Sue and John --_000_728f0b441bce47efa8a34890871cf075BLUPR05MB562namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support

 

Yours Irrespectively,<= o:p>

 

John=

 

From: Idr [mailto:idr-bounces@ietf.org] On= Behalf Of Susan Hares
Sent: Monday, December 23, 2013 9:09 AM
To: idr wg
Cc: draft-wu-idr-te-pm-bgp@tools.ietf.org
Subject: [Idr] draft-wu-idr-te-pm-bgp-03

 

idr people

 

This is to start a WG adoption call for this draft. It wil= l end on 1/6/13. 

 

http://datatracker.ietf.org/doc/draft-wu-idr-te-pm-bgp/<= /o:p>

 

BGP attribute for= North-Bound Distribution of Traffic Engineering (TE) performance Metrics

 

 

Two implementations in progress so feedback on this draft = is also welcomed by the authors.

 

Sue and John

 

--_000_728f0b441bce47efa8a34890871cf075BLUPR05MB562namprd05pro_-- From samita.chakrabarti@ericsson.com Fri Jan 3 14:33:00 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20EC61ADFF6 for ; Fri, 3 Jan 2014 14:33:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrTCf8BDkumv for ; Fri, 3 Jan 2014 14:32:57 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id B52C81ADFDA for ; Fri, 3 Jan 2014 14:32:56 -0800 (PST) X-AuditID: c6180641-b7fbd8e0000011cc-37-52c73a90fe07 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 98.CA.04556.09A37C25; Fri, 3 Jan 2014 23:32:48 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0347.000; Fri, 3 Jan 2014 17:32:21 -0500 From: Samita Chakrabarti To: Qin Wu , Susan Hares , idr wg Thread-Topic: draft-wu-idr-te-pm-bgp-03 Thread-Index: AQHPAEjjmlEPxuwPLkWINFi26qs0Fppzopew Date: Fri, 3 Jan 2014 22:32:20 +0000 Message-ID: References: <000901cf0001$a240b270$e6c21750$@ndzh.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_ECA43DA70480A3498E43C3471FB2E1F01C13AAF6eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXRPiO4Eq+NBBmtua1s8nruA1aJvwiF2 i1e3nzFZ/HnzisWBxaPlyFtWjyVLfjJ5zH59ndXjy+XPbAEsUVw2Kak5mWWpRfp2CVwZ23cu Yi44X1Rx4NdZxgbGzrQuRk4OCQETib4/fxkhbDGJC/fWs3UxcnEICRxhlFg/7z8zhLOMUeLt ukMsIFVsAlYSHb172EFsEYFwiT8dc1i7GDk4mAVCJR61GYCEhQXUJKZtuc8GUaIu8aTrITtI iYiAkcSeJieQMIuAisT1U3fBpvAK+Eq8OnmIHWJVE6PE8r/3wRKcAmESZ1/cBpvDCHTc91Nr mEBsZgFxiVtP5jNBHC0gsWTPeWYIW1Ti5eN/rBC2ssT3OY9YIOrzJdY9OMMKsUxQ4uTMJywT GEVnIRk1C0nZLCRlEHEdiQW7P7FB2NoSyxa+Zoaxzxx4zIQsvoCRfRUjR2lxalluupHhJkZg 9B2TYHPcwbjgk+UhRmkOFiVx3i9vnYOEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MPZ5LTwl cHtv1/mTdj5JmkumLa9RPmvKIGRWtejZ3C1PTI+05VnEz7JdcUvjZFBRs4vKw1eX987fH921 fhr3t/zrtleaszUWSE3e8FI3+0URt1hl36vpVy6kqs87euCDtGSH4mSpwCQdxfkL2EzYQlUO dL+JanKZdV7kpOCiHq90Npcd5eFHdiuxFGckGmoxFxUnAgBLOSLhjAIAAA== Cc: "draft-wu-idr-te-pm-bgp@tools.ietf.org" Subject: Re: [Idr] draft-wu-idr-te-pm-bgp-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 22:33:00 -0000 --_000_ECA43DA70480A3498E43C3471FB2E1F01C13AAF6eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am supportive of this document. Here are my comments on the draft for clarification and improvement: 1. Clarify how the performance data are originated. A clarification = on the assumption that BGP receives the link-state performance descriptors = via another BGP speaker or an IGP-TE implementation or a pointer to the sec= tion on BGP-LS (figure-1?) would be helpful. 2. Is this information (PM data) dynamically collected ? Averaged ove= r a period of time? Does the TLV format require additional information th= an just the PM value in some cases? [ for example, unidirectional delay: sh= ould it include an accuracy factor or observation period?] Not clear how = often this information is updated? 3. Section 4 of this document says: "These TLVs include a bit called the Anomalous (or "A") bit at the left-most bit after= length field of each TLV." -- Where is this defined in the diagram? A ref= erence will be helpful. Thanks, -Samita From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Qin Wu Sent: Monday, December 23, 2013 5:39 PM To: Susan Hares; idr wg Cc: draft-wu-idr-te-pm-bgp@tools.ietf.org Subject: Re: [Idr] draft-wu-idr-te-pm-bgp-03 Support as coauthor. We plan to implement it after it gets adoption. Regards! -Qin From: Susan Hares [mailto:shares@ndzh.com] Sent: Tuesday, December 24, 2013 1:09 AM To: idr wg Cc: draft-wu-idr-te-pm-bgp@tools.ietf.org; Qin Wu Subject: draft-wu-idr-te-pm-bgp-03 idr people This is to start a WG adoption call for this draft. It will end on 1/6/13. http://datatracker.ietf.org/doc/draft-wu-idr-te-pm-bgp/ BGP attribute for North-Bound Distribution of Traffic Engineering (TE) perf= ormance Metrics Two implementations in progress so feedback on this draft is also welcomed = by the authors. Sue and John --_000_ECA43DA70480A3498E43C3471FB2E1F01C13AAF6eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am supportive of thi= s document.

 

Here are my comments o= n the draft for clarification and improvement:

 

1.&n= bsp;      Clarify how th= e performance data are originated.  A clarification on the assumption = that BGP receives the link-state performance descriptors via another BGP sp= eaker or an IGP-TE implementation or a pointer to the section on BGP-LS (figure-1?) would be helpful.<= /span>

2.&n= bsp;      Is this inform= ation (PM data) dynamically collected ? Averaged over a period of time?&nbs= p; Does the TLV format  require additional information than just the P= M value in some cases? [ for example, unidirectional delay: should it include  an accuracy factor or  observation per= iod?] Not clear how often this information  is updated?

3.&n= bsp;      Section 4 of t= his document says: “These TLVs

include a bit c= alled the Anomalous (or "A") bit at the left-most bit  after= length field of each TLV.”  -- Where is this defined in the dia= gram? A reference will be helpful.

 

 

Thanks,

-Samita

 

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Qin Wu
Sent: Monday, December 23, 2013 5:39 PM
To: Susan Hares; idr wg
Cc: draft-wu-idr-te-pm-bgp@tools.ietf.org
Subject: Re: [Idr] draft-wu-idr-te-pm-bgp-03

 

Support as coauthor.

We plan to implement it after it gets adoption.

 

Regards!

-Qin

From: Susan Hares [mailto:s= hares@ndzh.com]
Sent: Tuesday, December 24, 2013 1:09 AM
To: idr wg
Cc: draft-w= u-idr-te-pm-bgp@tools.ietf.org; Qin Wu
Subject: draft-wu-idr-te-pm-bgp-03

 

idr people

 

This is to start a WG adoption = call for this draft. It will end on 1/6/13. 

 

http://datatracker.ietf.org/doc/draft-= wu-idr-te-pm-bgp/

 

= BGP attribute for North-Bound Distribution of Traffic Engineering (TE) perf= ormance Metrics

 

 

Two implementations in progress= so feedback on this draft is also welcomed by the authors.

 

Sue and John

 

--_000_ECA43DA70480A3498E43C3471FB2E1F01C13AAF6eusaamb103erics_-- From wwwrun@rfc-editor.org Mon Dec 23 18:23:26 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A59E1AE348 for ; Mon, 23 Dec 2013 18:23:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJA-sDsUIxV2 for ; Mon, 23 Dec 2013 18:23:24 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0381AE13A for ; Mon, 23 Dec 2013 18:23:24 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id A4CB37FC3A1; Mon, 23 Dec 2013 18:23:20 -0800 (PST) To: tbates@cisco.com, rchandra@sonoasystems.com, dkatz@juniper.com, yakov@juniper.com, , stbryant@cisco.com, adrian@olddog.co.uk, shares@ndzh.com, jgs@juniper.net From: RFC Errata System Message-Id: <20131224022320.A4CB37FC3A1@rfc-editor.org> Date: Mon, 23 Dec 2013 18:23:20 -0800 (PST) X-Mailman-Approved-At: Sun, 05 Jan 2014 11:14:53 -0800 Cc: idr@ietf.org, rfc-editor@rfc-editor.org Subject: [Idr] [Editorial Errata Reported] RFC4760 (3848) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Dec 2013 02:23:26 -0000 The following errata report has been submitted for RFC4760, "Multiprotocol Extensions for BGP-4". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4760&eid=3848 -------------------------------------- Type: Editorial Reported by: Ramakrishna DTV Section: 3 Original Text ------------- (b) to permit a router to advertise the Network Layer address of the router that should be used as the next hop to the destinations listed in the Network Layer Reachability Information field of the MP_NLRI attribute. Corrected Text -------------- (b) to permit a router to advertise the Network Layer address of the router that should be used as the next hop to the destinations listed in the Network Layer Reachability Information field of the MP_REACH_NLRI attribute. Notes ----- There is no attribute named "MP_NLRI". 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. -------------------------------------- RFC4760 (draft-ietf-idr-rfc2858bis-10) -------------------------------------- Title : Multiprotocol Extensions for BGP-4 Publication Date : January 2007 Author(s) : T. Bates, R. Chandra, D. Katz, Y. Rekhter Category : DRAFT STANDARD Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From wangdanhua@huawei.com Tue Dec 24 23:20:00 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E3D1AE24E for ; Tue, 24 Dec 2013 23:20:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.212 X-Spam-Level: * X-Spam-Status: No, score=1.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOHYvh6U_vvE for ; Tue, 24 Dec 2013 23:19:54 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 505791A1F19 for ; Tue, 24 Dec 2013 23:19:53 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZI77396; Wed, 25 Dec 2013 07:19:48 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 25 Dec 2013 07:18:57 +0000 Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 25 Dec 2013 07:19:47 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Wed, 25 Dec 2013 15:19:44 +0800 From: Wangdanhua To: Susan Hares , idr wg Thread-Topic: draft-wu-idr-te-pm-bgp-03 Thread-Index: Ac8AAWPdssnbKOftQE2H2DzRobdO/QBQCUlA Date: Wed, 25 Dec 2013 07:19:43 +0000 Message-ID: References: <000901cf0001$a240b270$e6c21750$@ndzh.com> In-Reply-To: <000901cf0001$a240b270$e6c21750$@ndzh.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.91] Content-Type: multipart/alternative; boundary="_000_AFD688AF30E249418739DBDC55B9C75B3595FE8Ankgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Sun, 05 Jan 2014 11:14:53 -0800 Cc: "draft-wu-idr-te-pm-bgp@tools.ietf.org" Subject: [Idr] =?gb2312?b?tPC4tDogZHJhZnQtd3UtaWRyLXRlLXBtLWJncC0wMw==?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Dec 2013 07:20:00 -0000 --_000_AFD688AF30E249418739DBDC55B9C75B3595FE8Ankgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 U3VwcG9ydCBhcyBjb2F1dGhvci4NCg0KDQq3orz+yMs6IFN1c2FuIEhhcmVzIFttYWlsdG86c2hh cmVzQG5kemguY29tXQ0Kt6LLzcqxvOQ6IDIwMTPE6jEy1MIyNMjVIDE6MDkNCsrVvP7IyzogaWRy IHdnDQqzrcvNOiBkcmFmdC13dS1pZHItdGUtcG0tYmdwQHRvb2xzLmlldGYub3JnOyBRaW4gV3UN Ctb3zOI6IGRyYWZ0LXd1LWlkci10ZS1wbS1iZ3AtMDMNCg0KaWRyIHBlb3BsZQ0KDQpUaGlzIGlz IHRvIHN0YXJ0IGEgV0cgYWRvcHRpb24gY2FsbCBmb3IgdGhpcyBkcmFmdC4gSXQgd2lsbCBlbmQg b24gMS82LzEzLg0KDQpodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXd1LWlk ci10ZS1wbS1iZ3AvDQoNCkJHUCBhdHRyaWJ1dGUgZm9yIE5vcnRoLUJvdW5kIERpc3RyaWJ1dGlv biBvZiBUcmFmZmljIEVuZ2luZWVyaW5nIChURSkgcGVyZm9ybWFuY2UgTWV0cmljcw0KDQoNClR3 byBpbXBsZW1lbnRhdGlvbnMgaW4gcHJvZ3Jlc3Mgc28gZmVlZGJhY2sgb24gdGhpcyBkcmFmdCBp cyBhbHNvIHdlbGNvbWVkIGJ5IHRoZSBhdXRob3JzLg0KDQpTdWUgYW5kIEpvaG4NCg0K --_000_AFD688AF30E249418739DBDC55B9C75B3595FE8Ankgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Support as coauthor.

 

 

=B7=A2=BC=FE=C8=CB: Susan Hares [mailto:s= hares@ndzh.com]
=B7=A2=CB=CD= =CA=B1=BC=E4: 2013=C4=EA12=D4=C2= 24=C8=D5 1:09
=CA=D5=BC=FE=C8=CB: idr wg
=B3=AD=CB=CD: draft-wu-idr-te-pm-bgp@tools.ietf.org; Qin Wu
=D6=F7=CC=E2: draft-wu-idr-te-pm-bgp-03

 

idr peopl= e

 

This is to start a WG adoption call for thi= s draft. It will end on 1/6/13. 

 

http://datatracker.ietf.org/doc/draft-wu-idr-te-pm= -bgp/

 

BG= P attribute for North-Bound Distribution of Traffic Engineering (TE) perfor= mance Metrics

 

 

Two implementations in progress so feedback= on this draft is also welcomed by the authors.

 

Sue and John

 <= /p>

--_000_AFD688AF30E249418739DBDC55B9C75B3595FE8Ankgeml501mbschi_-- From wwwrun@rfc-editor.org Wed Dec 25 19:04:12 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB831AE10F for ; Wed, 25 Dec 2013 19:04:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmKQFV395ylK for ; Wed, 25 Dec 2013 19:04:10 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id B84771AE10C for ; Wed, 25 Dec 2013 19:04:10 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 99D157FC37E; Wed, 25 Dec 2013 19:04:06 -0800 (PST) To: tbates@cisco.com, rchandra@sonoasystems.com, dkatz@juniper.com, yakov@juniper.com, , stbryant@cisco.com, adrian@olddog.co.uk, shares@ndzh.com, jgs@juniper.net From: RFC Errata System Message-Id: <20131226030406.99D157FC37E@rfc-editor.org> Date: Wed, 25 Dec 2013 19:04:06 -0800 (PST) X-Mailman-Approved-At: Sun, 05 Jan 2014 11:14:53 -0800 Cc: idr@ietf.org, rfc-editor@rfc-editor.org Subject: [Idr] [Editorial Errata Reported] RFC4760 (3849) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Dec 2013 03:04:12 -0000 The following errata report has been submitted for RFC4760, "Multiprotocol Extensions for BGP-4". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4760&eid=3849 -------------------------------------- Type: Editorial Reported by: Ramakrishna DTV Section: 3 Original Text ------------- The next hop information carried in the MP_REACH_NLRI path attribute defines the Network Layer address of the router that SHOULD be used as the next hop to the destinations listed in the MP_NLRI attribute in the UPDATE message. Corrected Text -------------- The next hop information carried in the MP_REACH_NLRI path attribute defines the Network Layer address of the router that SHOULD be used as the next hop to the destinations listed in the NLRI field of the MP_REACH_NLRI attribute in the UPDATE message. Notes ----- There is no attribute named "MP_NLRI". 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. -------------------------------------- RFC4760 (draft-ietf-idr-rfc2858bis-10) -------------------------------------- Title : Multiprotocol Extensions for BGP-4 Publication Date : January 2007 Author(s) : T. Bates, R. Chandra, D. Katz, Y. Rekhter Category : DRAFT STANDARD Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From bill.wu@huawei.com Sun Jan 5 20:07:51 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C79E1ADF80 for ; Sun, 5 Jan 2014 20:07:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1Hw9BRWhbHT for ; Sun, 5 Jan 2014 20:07:47 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 43F311ADF79 for ; Sun, 5 Jan 2014 20:07:47 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCE11716; Mon, 06 Jan 2014 04:07:37 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 6 Jan 2014 04:07:19 +0000 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 6 Jan 2014 04:07:36 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Mon, 6 Jan 2014 12:07:33 +0800 From: Qin Wu To: Daniel King , "idr@ietf.org" Thread-Topic: [Idr] PCE Text within draft-wu-idr-te-pm-bgp-03 Thread-Index: Ac8HRTBjAN2bhM9QQpSxQsDJk5pbmADTZDew Date: Mon, 6 Jan 2014 04:07:33 +0000 Message-ID: References: <012601cf0745$733bf200$59b3d600$@olddog.co.uk> In-Reply-To: <012601cf0745$733bf200$59b3d600$@olddog.co.uk> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA43C70307nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Idr] PCE Text within draft-wu-idr-te-pm-bgp-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 04:07:51 -0000 --_000_B8F9A780D330094D99AF023C5877DABA43C70307nkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Dan: From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Daniel King Sent: Thursday, January 02, 2014 7:02 AM To: idr@ietf.org Subject: [Idr] PCE Text within draft-wu-idr-te-pm-bgp-03 Hi Authors, Useful I-D, and nice to see H-PCE Architecture (RFC6805) being discussed in= use cases. My comment is a suggested text update for Section 3.1 (MPLS-TE with PCE): >> For inter-AS path computation the Hierarchical PCE (H-PCE) [RFC6805] may be= used to compute the optimal sequence of domains. Within the H-PCE architec= ture, the child PCE communicates domain connectivity information to the par= ent PCE, and the parent PCE will use this information to compute a multi-do= main path based on the optimal TE links between domains for the end-to-end = path. The following figure demonstrates how a child PCE may obtain TE performance= information beyond that contained in the LINK_STATE attributes [I.D-ietf-i= dr-ls-distribution] using the mechanism described in this document. [Qin]: Your proposed change looks good except you say "demonstrates how a c= hild PCE may obtain TE performance", I think in H-PCE case, it is parent PC= E who need to build TED based on domain connectivity information, i.e., int= er-AS TE performance information. Child PCE provide that information. Intra= -domain information can not be provided to parent PCE based on RFC6805 sinc= e providing intr-domain infor would violate the confidentiality and scaling= principles(See 4.4 of RFC6805). For intra-domain path computation, parent PCE still need to rely on child P= CE for per-domain path calculation. Besides H-PCE case, I think there are other cases where one external PCE ca= n gather information from other Ass. In those case, providing intra-domain= info from one AS to the PCE in another AS will not violate the confidentiality and scaling principles provided by RFC6805. << Also an FYI, we (PCE WG) adopted the H-PCE extensions document (http://tool= s.ietf.org/html/draft-ietf-pce-hierarchy-extensions). So if you are discuss= ing configuration examples, you may also want to reference this document as= well. [Qin]: I can add this reference in your proposed change. Br, Dan. --_000_B8F9A780D330094D99AF023C5877DABA43C70307nkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Dan:

 

From: Idr [mai= lto:idr-bounces@ietf.org] On Behalf Of Daniel King
Sent: Thursday, January 02, 2014 7:02 AM
To: idr@ietf.org
Subject: [Idr] PCE Text within draft-wu-idr-te-pm-bgp-03<= /span>

 

Hi Authors, <= /p>


Useful I-D, and nice to see H-PCE Architecture (RFC6805) being discussed in= use cases.

 

My comment is a suggested text = update for Section 3.1 (MPLS-TE with PCE):

 

>> 

For inter-AS path computation t= he Hierarchical PCE (H-PCE) [RFC6805] may be used to compute the optimal se= quence of domains. Within the H-PCE architecture, the child PCE communicate= s domain connectivity information to the parent PCE, and the parent PCE will use this information to compute a = multi-domain path based on the optimal TE links between domains for the end= -to-end path.

 

The following figure demonstrat= es how a child PCE may obtain TE performance information beyond that contai= ned in the LINK_STATE attributes [I.D-ietf-idr-ls-distribution] using the m= echanism described in this document.=

&n= bsp;

[Qin]: = Your proposed change looks good except you say “demonstrates how a child PCE may obtain TE performance”, I think in H-PCE case, it is parent PCE who need to build TED based on domain connect= ivity information, i.e., inter-AS TE performance information. Child PCE pro= vide that information. Intra-domain information can not be provided to pare= nt PCE based on RFC6805 since providing intr-domain infor would violate the confidentiality and scaling principles= (See 4.4 of RFC6805).

For int= ra-domain path computation, parent PCE still need to rely on child PCE for = per-domain path calculation.

&n= bsp;

Besides= H-PCE case, I think there are other cases where one external PCE can gathe= r information from other Ass. In those case,  providing intra-domain i= nfo from one AS to the PCE in another AS will not

violate= the confidentiality and scaling principles provided by RFC6805.=

<< 

 

Also an FYI, we (PCE WG) adopte= d the H-PCE extensions document (http://tools.ietf.org/html/draft-ietf-pce-= hierarchy-extensions). So if you are discussing configuration examples, you may also want to reference this doc= ument as well.  

&n= bsp;

[Qin]: = I can add this reference in your proposed change.

 

Br, Dan.

--_000_B8F9A780D330094D99AF023C5877DABA43C70307nkgeml501mbschi_-- From bill.wu@huawei.com Sun Jan 5 20:16:18 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D75B1ADF6A for ; Sun, 5 Jan 2014 20:16:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OnGhtVwKt--O for ; Sun, 5 Jan 2014 20:16:15 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 60C911ADF64 for ; Sun, 5 Jan 2014 20:16:14 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZQ80903; Mon, 06 Jan 2014 04:16:04 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 6 Jan 2014 04:15:38 +0000 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 6 Jan 2014 04:16:02 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Mon, 6 Jan 2014 12:15:59 +0800 From: Qin Wu To: Samita Chakrabarti , Susan Hares , idr wg Thread-Topic: draft-wu-idr-te-pm-bgp-03 Thread-Index: Ac8AAWPdssnbKOftQE2H2DzRobdO/QARzyowAhH+1AAAgQ8hwA== Date: Mon, 6 Jan 2014 04:15:58 +0000 Message-ID: References: <000901cf0001$a240b270$e6c21750$@ndzh.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA43C70318nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-wu-idr-te-pm-bgp@tools.ietf.org" Subject: Re: [Idr] draft-wu-idr-te-pm-bgp-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 04:16:18 -0000 --_000_B8F9A780D330094D99AF023C5877DABA43C70318nkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Samita: Thanks for your comments. See my reply inline below. Regards! -Qin From: Samita Chakrabarti [mailto:samita.chakrabarti@ericsson.com] Sent: Saturday, January 04, 2014 6:32 AM To: Qin Wu; Susan Hares; idr wg Cc: draft-wu-idr-te-pm-bgp@tools.ietf.org Subject: RE: draft-wu-idr-te-pm-bgp-03 I am supportive of this document. Here are my comments on the draft for clarification and improvement: 1. Clarify how the performance data are originated. A clarification = on the assumption that BGP receives the link-state performance descriptors = via another BGP speaker or an IGP-TE implementation or a pointer to the sec= tion on BGP-LS (figure-1?) would be helpful. [Qin]: Good comment, I propose to add one sentence at the end of introducti= on section as follows: " The network performance information can be distributed in the same way as l= ink state information distribution, i.e., either directly or via a peer BGP speaker (see figure 1= of [I.D-ietf-idr-ls-distribution]). " 2. Is this information (PM data) dynamically collected ? Averaged ove= r a period of time? Does the TLV format require additional information th= an just the PM value in some cases? [ for example, unidirectional delay: sh= ould it include an accuracy factor or observation period?] Not clear how = often this information is updated? [Qin]: Yes, the information is dynamic collected. It is obtained by a filte= r that is reasonably representative of an average or calculated as rolling averages where the av= eraging period MUST be a configurable period of time. The measurement interval or re-advertisem= ent interval are pre-provisioned and can be defined in the same way as one for ISIS-TE-Metri= c-extension draft. So I propose the following change in section 4: OLD TEXT: " Consistent with existing ISIS TE specifications [ISIS-TE-METRIC], the bandwidth advertisements,the delay and delay variation advertisements, packetloss defined in this document MUST be encoded in the same unit as one defined in IS-IS Extended IS Reachability sub-TLVs [ISIS-TE-METRIC]. All values (except residual bandwidth) MUST be calculated as rolling averages where the averaging period MUST be a configurable period of time. " NEW TEXT: " Consistent with existing ISIS TE specifications [ISIS-TE-METRIC], the bandwidth advertisements, the delay and delay variation advertisements, packet loss defined in this document MUST be encoded in the same unit as one defined in IS-IS Extended IS Reachability sub-TLVs [ISIS-TE-METRIC]. All values (except residual bandwidth) MUST be obtained by a filter that is reasonably representative of an average or calculated as rolling averages where the averaging period MUST be a configurable period of time. The measurement interval, any filter coefficients, and any advertisement intervals MUST be configurable per sub-TLV in the same way as ones defined in section 5 of [ISIS-TE-METRIC]. " 3. Section 4 of this document says: "These TLVs include a bit called the Anomalous (or "A") bit at the left-most bit after= length field of each TLV." -- Where is this defined in the diagram? A ref= erence will be helpful. [Qin]: Good point. I propose the following change in section 4 as follows: OLD TEXT: " These TLVs include a bit called the Anomalous (or "A") bit at the left-most= bit after length field of each TLV. " NEW TEXT: " These TLVs include a bit called the Anomalous (or "A") bit at the left-most= bit after length field of each TLV defined in figure 4 of [[I.D-ietf-idr-ls-dis= tribution]]. " Thanks, -Samita From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Qin Wu Sent: Monday, December 23, 2013 5:39 PM To: Susan Hares; idr wg Cc: draft-wu-idr-te-pm-bgp@tools.ietf.org Subject: Re: [Idr] draft-wu-idr-te-pm-bgp-03 Support as coauthor. We plan to implement it after it gets adoption. Regards! -Qin From: Susan Hares [mailto:shares@ndzh.com] Sent: Tuesday, December 24, 2013 1:09 AM To: idr wg Cc: draft-wu-idr-te-pm-bgp@tools.ietf.org; Qin Wu Subject: draft-wu-idr-te-pm-bgp-03 idr people This is to start a WG adoption call for this draft. It will end on 1/6/13. http://datatracker.ietf.org/doc/draft-wu-idr-te-pm-bgp/ BGP attribute for North-Bound Distribution of Traffic Engineering (TE) perf= ormance Metrics Two implementations in progress so feedback on this draft is also welcomed = by the authors. Sue and John --_000_B8F9A780D330094D99AF023C5877DABA43C70318nkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Samita:=

Thanks for your commen= ts.

See my reply inline be= low.

 

Regards!

-Qin=

 

From: Samita C= hakrabarti [mailto:samita.chakrabarti@ericsson.com]
Sent: Saturday, January 04, 2014 6:32 AM
To: Qin Wu; Susan Hares; idr wg
Cc: draft-wu-idr-te-pm-bgp@tools.ietf.org
Subject: RE: draft-wu-idr-te-pm-bgp-03

 

I am supportive of thi= s document.

 

Here are my comments o= n the draft for clarification and improvement:

 

1.&= nbsp;      Clarify how th= e performance data are originated.  A clarification on the assumption = that BGP receives the link-state performance descriptors via another BGP sp= eaker or an IGP-TE implementation or a pointer to the section on BGP-LS (figure-1?) would be helpful.<= /span>

[Qin]: Good comment, I propose to add one sentence at the = end of introduction section as follows:

“

The network performance information can be distributed in = the same way as link state information

distribution, i.e., either directly or via a peer BGP spea= ker (see figure 1 of

[I.D-ietf-idr-ls-distribution]).

 

”

2.&= nbsp;      Is this inform= ation (PM data) dynamically collected ? Averaged over a period of time?&nbs= p; Does the TLV format  require additional information than just the P= M value in some cases? [ for example, unidirectional delay: should it include  an accuracy factor or  observation per= iod?] Not clear how often this information  is updated?

 

 

[Qin]: Yes, the information is dynamic collected. It is ob= tained by a filter that is reasonably

representative of an average or calculated as rolling aver= ages where the averaging period MUST

be a configurable period of time. The measurement interval= or re-advertisement interval are

pre-provisioned and can be defined in the same way as one = for ISIS-TE-Metric-extension draft.

So I propose the following change in section 4:=

OLD TEXT:

“

   Consistent with existing ISIS TE specificatio= ns [ISIS-TE-METRIC], the

   bandwidth advertisements,the delay and delay = variation

   advertisements, packetloss defined in this do= cument MUST be encoded

   in the same unit as one defined in IS-IS Exte= nded IS Reachability

   sub-TLVs [ISIS-TE-METRIC].  All values (= except residual bandwidth)

   MUST be calculated as rolling averages where = the averaging period

   MUST be a configurable period of time.= <= /o:p>

 

”

NEW TEXT:

“

   Consistent with existing ISIS TE specificatio= ns [ISIS-TE-METRIC], the

   bandwidth advertisements, the delay and delay variation

   advertisements, packet loss defined in this document MUST be encoded

   in the same unit as one defined in IS-IS Exte= nded IS Reachability

   sub-TLVs [ISIS-TE-METRIC].  All values (= except residual bandwidth)

   MUST be obtained by a filter that is reasonab= ly representative of

   an average or calculated as rolling averages where the averaging period

   MUST be a configurable period of time.=  =   The measurement interval,

   any filter coefficients, and any adverti= sement intervals MUST be

   configurable per sub-TLV in the same way= as ones defined in

   section 5 of [ISIS-TE-METRIC].

 

”

 

 

3.&= nbsp;      Section 4 of t= his document says: “These TLVs

include a bit c= alled the Anomalous (or "A") bit at the left-most bit  after= length field of each TLV.”  -- Where is this defined in the dia= gram? A reference will be helpful.

 

[Qin]: Good point. I propose the following change in secti= on 4 as follows:

OLD TEXT:

“

These TLVs include a bit called the Anomalous (or "A&= quot;) bit at the left-most bit

after length field of each TLV. 

”

NEW TEXT:

“

These TLVs include a bit called the Anomalous (or "A") bit at the left-most= bit

after length field of each TLV defined in figure 4 of [[= I.D-ietf-idr-ls-distribution]]. 

”

 

Thanks,

-Samita

 

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Qin Wu
Sent: Monday, December 23, 2013 5:39 PM
To: Susan Hares; idr wg
Cc: draft-wu-idr-te-pm-bgp@tools.ietf.org
Subject: Re: [Idr] draft-wu-idr-te-pm-bgp-03

 

Support as coauthor.

We plan to implement it after it gets adoption.

 

Regards!

-Qin

From: Susan Hares [mailto= :shares@ndzh.com]
Sent: Tuesday, December 24, 2013 1:09 AM
To: idr wg
Cc: draft-w= u-idr-te-pm-bgp@tools.ietf.org; Qin Wu
Subject: draft-wu-idr-te-pm-bgp-03

 

idr people

 

This is to start a WG adoptio= n call for this draft. It will end on 1/6/13. 

 

http://datatracker.ietf.org/doc/draf= t-wu-idr-te-pm-bgp/

 

 

 

Two implementations in progre= ss so feedback on this draft is also welcomed by the authors.

 

Sue and John

 =

--_000_B8F9A780D330094D99AF023C5877DABA43C70318nkgeml501mbschi_-- From daniel@olddog.co.uk Sun Jan 5 23:18:57 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F39FB1ADFCF for ; Sun, 5 Jan 2014 23:18:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQr1VwHeog00 for ; Sun, 5 Jan 2014 23:18:53 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB591ADFC2 for ; Sun, 5 Jan 2014 23:18:52 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s067IYBI027961; Mon, 6 Jan 2014 07:18:34 GMT Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s067IXjS027946 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 6 Jan 2014 07:18:33 GMT From: "Daniel King" To: "'Qin Wu'" , References: <012601cf0745$733bf200$59b3d600$@olddog.co.uk> In-Reply-To: Date: Mon, 6 Jan 2014 07:18:30 -0000 Message-ID: <002e01cf0aaf$80cac280$82604780$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002F_01CF0AAF.80CCBE50" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQM4pm9is7Oro6y10ih/nF7Ii3pr6gFMmZC8l5miUAA= Content-Language: en-gb Subject: Re: [Idr] PCE Text within draft-wu-idr-te-pm-bgp-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 07:18:57 -0000 This is a multipart message in MIME format. ------=_NextPart_000_002F_01CF0AAF.80CCBE50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Qin, The scaling and confidentially especially relates to the internal topologies of the Child domains. I would agree that having the Parent PCE compute both the intra-domain and inter-domain path would be bad. A variety of methods exist to provide the parent PCE the inter-domain information. Using BGP-LS as a northbound distribution mechanism, there would be a BGP speaker in each domain that sends the necessary information to a BGP speaker in the parent domain. This may be the Child PCE disseminating inter-domain adjacency information to the Parent PCE, but using policy to ensure that information is restricted to inter-domain connectivity. Or. A Parent PCE may also simply participate in the IGP of a domain in order to learn about connected domains, and/or learn inter-domain connectivity from a BGP Route Reflector (filtering), or indeed using PCEP Notifications but this may upset some in the PCE Working Group. What knowledge is provided to the Parent PCE may be dependent on who is "responsible" for the Parent PCE and domains, single provider or multiple providers. Finally, the Parent PCE may also only simply send a proposed sequence of domains to the ingress domain Child PCE so that the end-to-end domain path can be constructed using Per Domain or Backwards Recursive Path Computation could be used, instead of H-PCE path computation. Either way, your suggested text update is fine and all of these permutations of how the Parent PCE may learn inter-domain information will have to be considered for the H-PCE extension work. Br, Dan. From: Qin Wu [mailto:bill.wu@huawei.com] Sent: 06 January 2014 04:08 To: Daniel King; idr@ietf.org Subject: RE: [Idr] PCE Text within draft-wu-idr-te-pm-bgp-03 Hi, Dan: From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Daniel King Sent: Thursday, January 02, 2014 7:02 AM To: idr@ietf.org Subject: [Idr] PCE Text within draft-wu-idr-te-pm-bgp-03 Hi Authors, Useful I-D, and nice to see H-PCE Architecture (RFC6805) being discussed in use cases. My comment is a suggested text update for Section 3.1 (MPLS-TE with PCE): >> For inter-AS path computation the Hierarchical PCE (H-PCE) [RFC6805] may be used to compute the optimal sequence of domains. Within the H-PCE architecture, the child PCE communicates domain connectivity information to the parent PCE, and the parent PCE will use this information to compute a multi-domain path based on the optimal TE links between domains for the end-to-end path. The following figure demonstrates how a child PCE may obtain TE performance information beyond that contained in the LINK_STATE attributes [I.D-ietf-idr-ls-distribution] using the mechanism described in this document. [Qin]: Your proposed change looks good except you say "demonstrates how a child PCE may obtain TE performance", I think in H-PCE case, it is parent PCE who need to build TED based on domain connectivity information, i.e., inter-AS TE performance information. Child PCE provide that information. Intra-domain information can not be provided to parent PCE based on RFC6805 since providing intr-domain infor would violate the confidentiality and scaling principles(See 4.4 of RFC6805). For intra-domain path computation, parent PCE still need to rely on child PCE for per-domain path calculation. Besides H-PCE case, I think there are other cases where one external PCE can gather information from other Ass. In those case, providing intra-domain info from one AS to the PCE in another AS will not violate the confidentiality and scaling principles provided by RFC6805. << Also an FYI, we (PCE WG) adopted the H-PCE extensions document (http://tools.ietf.org/html/draft-ietf-pce-hierarchy-extensions). So if you are discussing configuration examples, you may also want to reference this document as well. [Qin]: I can add this reference in your proposed change. Br, Dan. ------=_NextPart_000_002F_01CF0AAF.80CCBE50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Qin, =

 

The scaling and = confidentially especially relates to the internal topologies of the = Child domains. I would agree that having the Parent PCE compute both the = intra-domain and inter-domain path would be bad. =

 

A variety of methods = exist to provide the parent PCE the inter-domain information. Using = BGP-LS as a northbound distribution mechanism, there would be a BGP = speaker in each domain that sends the necessary information to a BGP = speaker in the parent domain. This may be the Child PCE disseminating = inter-domain adjacency information to the Parent PCE, but using policy = to ensure that information is restricted to inter-domain = connectivity.

 

Or. =

 

A Parent PCE may also = simply participate in the IGP of a domain in order to learn about = connected domains, and/or learn inter-domain connectivity from a BGP = Route Reflector (filtering), or indeed using PCEP Notifications but this = may upset some in the PCE Working Group. What knowledge is provided to = the Parent PCE may be dependent on who is “responsible” for = the Parent PCE and domains, single provider or multiple providers. =

 

Finally, the Parent = PCE may also only simply send a proposed sequence of domains to the = ingress domain Child PCE so that the end-to-end domain path can be = constructed using Per Domain or Backwards Recursive Path Computation = could be used, instead of H-PCE path = computation.

=

Either way, your = suggested text update is fine and all of these permutations of how the = Parent PCE may learn inter-domain information will have to be considered = for the H-PCE extension work.

 

Br, Dan. =

 

From: Qin Wu = [mailto:bill.wu@huawei.com]
Sent: 06 January 2014 = 04:08
To: Daniel King; idr@ietf.org
Subject: RE: = [Idr] PCE Text within = draft-wu-idr-te-pm-bgp-03

 

Hi, Dan:

 

From:= Idr [mailto:idr-bounces@ietf.org] = On Behalf Of Daniel King
Sent: Thursday, January 02, = 2014 7:02 AM
To: idr@ietf.org
Subject: [Idr] = PCE Text within = draft-wu-idr-te-pm-bgp-03

 

Hi Authors,


Useful I-D, and nice to see H-PCE Architecture = (RFC6805) being discussed in use cases.

 

My comment = is a suggested text update for Section 3.1 (MPLS-TE with = PCE):

 

>> 

For = inter-AS path computation the Hierarchical PCE (H-PCE) [RFC6805] may be = used to compute the optimal sequence of domains. Within the H-PCE = architecture, the child PCE communicates domain connectivity information = to the parent PCE, and the parent PCE will use this information to = compute a multi-domain path based on the optimal TE links between = domains for the end-to-end path.

 

The = following figure demonstrates how a child PCE may obtain TE performance = information beyond that contained in the LINK_STATE attributes = [I.D-ietf-idr-ls-distribution] using the mechanism described in this = document.

 

[Qin]: Your proposed = change looks good except you say “demonstrates how a child = PCE may obtain TE performance”, I = think in H-PCE case, it is parent PCE who need to build TED based on = domain connectivity information, i.e., inter-AS TE performance = information. Child PCE provide that information. Intra-domain = information can not be provided to parent PCE based on RFC6805 since = providing intr-domain infor would violate the confidentiality and = scaling principles(See 4.4 of RFC6805).

For intra-domain path = computation, parent PCE still need to rely on child PCE for per-domain = path calculation.

 

Besides H-PCE case, I = think there are other cases where one external PCE can gather = information from other Ass. In those case,  providing intra-domain = info from one AS to the PCE in another AS will = not

violate the confidentiality and scaling = principles provided by RFC6805.

<< 

 

Also an FYI, = we (PCE WG) adopted the H-PCE extensions document (h= ttp://tools.ietf.org/html/draft-ietf-pce-hierarchy-extensions). So = if you are discussing configuration examples, you may also want to = reference this document as well.  

 

[Qin]: I can add this = reference in your proposed change.

 

Br, Dan. =

------=_NextPart_000_002F_01CF0AAF.80CCBE50-- From Roland.Schott@telekom.de Mon Jan 6 08:49:10 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 981631AE0E3 for ; Mon, 6 Jan 2014 08:49:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.787 X-Spam-Level: X-Spam-Status: No, score=-2.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTxXgDh8Yg2m for ; Mon, 6 Jan 2014 08:49:09 -0800 (PST) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id 024371AE042 for ; Mon, 6 Jan 2014 08:49:08 -0800 (PST) Received: from he113445.emea1.cds.t-internal.com ([10.134.93.105]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 06 Jan 2014 17:48:59 +0100 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE113445.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 6 Jan 2014 17:48:59 +0100 From: To: Date: Mon, 6 Jan 2014 17:48:59 +0100 Thread-Topic: Re: [Idr] draft-wu-idr-te-pm-bgp-03 Thread-Index: Ac8K/zI44pVuZqe6Sb6onkx7M/b8LA== Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D1976CFE372@HE111648.emea1.cds.t-internal.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_580BEA5E3B99744AB1F5BFF5E9A3C67D1976CFE372HE111648emea1_" MIME-Version: 1.0 Subject: Re: [Idr] draft-wu-idr-te-pm-bgp-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 16:49:10 -0000 --_000_580BEA5E3B99744AB1F5BFF5E9A3C67D1976CFE372HE111648emea1_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, in my opinion the WG should adopt this work. The reference about the calculation should be pointed out. Regards Roland --------------------- idr people This is to start a WG adoption call for this draft. It will end on 1/6/13. http://datatracker.ietf.org/doc/draft-wu-idr-te-pm-bgp/ BGP attribute for North-Bound Distribution of Traffic Engineering (TE) perf= ormance Metrics Two implementations in progress so feedback on this draft is also welcomed = by the authors. Sue and John --_000_580BEA5E3B99744AB1F5BFF5E9A3C67D1976CFE372HE111648emea1_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi all,
 
in my opinion the WG should adopt this work.
The reference about the calculation should be pointed out.
 
 
Regards
 
Roland
 
 
 
 
 
---------------------
 
idr people
 
This is to start a WG adoption call for this dra= ft. It will end on 1/6/13. 
 
 
BGP attribute for North-Bound Distribution of Tr= affic Engineering (TE) performance Metrics
 
 
Two implementations in progress so feedback on t= his draft is also welcomed by the authors.
 
Sue and John
 
 
 --_000_580BEA5E3B99744AB1F5BFF5E9A3C67D1976CFE372HE111648emea1_-- From maho@lab.dtag.de Tue Jan 7 01:29:08 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 272391ADF64 for ; Tue, 7 Jan 2014 01:29:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.339 X-Spam-Level: X-Spam-Status: No, score=-1.339 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2R0MqbyVw_e for ; Tue, 7 Jan 2014 01:29:06 -0800 (PST) Received: from owl.lab.dtag.de (Owl.lab.DTAG.DE [194.25.1.236]) by ietfa.amsl.com (Postfix) with ESMTP id DBC031ADEC8 for ; Tue, 7 Jan 2014 01:29:05 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by owl.lab.dtag.de (Postfix) with ESMTP id B21E35972D5 for ; Tue, 7 Jan 2014 10:28:55 +0100 (CET) Received: from tsunami-hippogryff-91.lab.dtag.de (o.Hippogryff.lab.dtag.de [194.25.10.166]) by owl.lab.dtag.de (Postfix) with ESMTPSA id 8FBD95972D2 for ; Tue, 7 Jan 2014 10:28:55 +0100 (CET) Message-ID: <52CBC8D7.3040008@lab.dtag.de> Date: Tue, 07 Jan 2014 10:28:55 +0100 From: Martin Horneffer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: idr@ietf.org References: <000901cf0001$a240b270$e6c21750$@ndzh.com> In-Reply-To: <000901cf0001$a240b270$e6c21750$@ndzh.com> Content-Type: multipart/alternative; boundary="------------040202030606030703080308" Subject: Re: [Idr] draft-wu-idr-te-pm-bgp-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 09:29:08 -0000 This is a multi-part message in MIME format. --------------040202030606030703080308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Support. Best regards, Martin Horneffer Am 23.12.13 18:08, schrieb Susan Hares: > > idr people > > This is to start a WG adoption call for this draft. It will end on > 1/6/13. > > http://datatracker.ietf.org/doc/draft-wu-idr-te-pm-bgp/ > > BGP attribute for North-Bound Distribution of Traffic Engineering (TE) > performance Metrics > > Two implementations in progress so feedback on this draft is also > welcomed by the authors. > > Sue and John > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr ############################################## # Mail Account for technical purposes only ############################################## --------------040202030606030703080308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Support.

Best regards,
Martin Horneffer


Am 23.12.13 18:08, schrieb Susan Hares:

idr people

 

This is to start a WG adoption call for this draft. It will end on 1/6/13. 

 

http://datatracker.ietf.org/doc/draft-wu-idr-te-pm-bgp/

 

BGP attribute for North-Bound Distribution of Traffic Engineering (TE) performance Metrics

 

 

Two implementations in progress so feedback on this draft is also welcomed by the authors.

 

Sue and John

 



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



##############################################
# Mail Account for technical purposes only
##############################################

--------------040202030606030703080308-- From shares@ndzh.com Wed Jan 8 17:59:28 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA6361ADFC4 for ; Wed, 8 Jan 2014 17:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.646 X-Spam-Level: *** X-Spam-Status: No, score=3.646 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebpnNrlGasmH for ; Wed, 8 Jan 2014 17:59:27 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 275001ADFBF for ; Wed, 8 Jan 2014 17:59:27 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: References: <000901cf0001$a240b270$e6c21750$@ndzh.com> <52CBC8D7.3040008@lab.dtag.de> In-Reply-To: <52CBC8D7.3040008@lab.dtag.de> Date: Wed, 8 Jan 2014 20:59:12 -0500 Message-ID: <015c01cf0cde$6550c960$2ff25c20$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_015D_01CF0CB4.7C7D3260" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH5X/7YseWE7Nd5hKNxWH9GAkpXfAHmXGWvmhfHx3A= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: draft-wu-idr-te-pm-bgp@tools.ietf.org Subject: Re: [Idr] draft-wu-idr-te-pm-bgp-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 01:59:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_015D_01CF0CB4.7C7D3260 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This draft has been accepted as a IDR draft. Please submit it as draft-ietf-idr-te-pm-bgp Sue Hares and John Scudder From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Martin Horneffer Sent: Tuesday, January 07, 2014 4:29 AM To: idr@ietf.org Subject: Re: [Idr] draft-wu-idr-te-pm-bgp-03 idr people This is to start a WG adoption call for this draft. It will end on 1/6/13. http://datatracker.ietf.org/doc/draft-wu-idr-te-pm-bgp/ BGP attribute for North-Bound Distribution of Traffic Engineering (TE) performance Metrics ------=_NextPart_000_015D_01CF0CB4.7C7D3260 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This draft has been = accepted as a IDR draft.  Please submit it = as

 

draft-ietf-idr-te-pm-bgp =

 

Sue Hares and John = Scudder

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Martin = Horneffer
Sent: Tuesday, January 07, 2014 4:29 = AM
To: idr@ietf.org
Subject: Re: [Idr] = draft-wu-idr-te-pm-bgp-03

 

idr people =

 

This is to start a = WG adoption call for this draft. It will end on 1/6/13.  =

 

http://d= atatracker.ietf.org/doc/draft-wu-idr-te-pm-bgp/

=

 

BGP attribute for North-Bound Distribution of = Traffic Engineering (TE) performance Metrics

 

 

 

------=_NextPart_000_015D_01CF0CB4.7C7D3260-- From shares@ndzh.com Wed Jan 8 20:43:09 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1A761AE123 for ; Wed, 8 Jan 2014 20:43:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.845 X-Spam-Level: ** X-Spam-Status: No, score=2.845 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xTcCDUIxc1M for ; Wed, 8 Jan 2014 20:43:07 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3771AE0A0 for ; Wed, 8 Jan 2014 20:43:06 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "idr wg" Date: Wed, 8 Jan 2014 23:42:52 -0500 Message-ID: <01a101cf0cf5$42797290$c76c57b0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01A2_01CF0CCB.59A71410" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8M9Sng1Sc20E2AQYmvUmzH4ulsgw== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: draft-ietf-idr-aigp@tools.ietf.org Subject: [Idr] IPR on draft-ietf-idr-aigp-14.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 04:43:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01A2_01CF0CCB.59A71410 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Draft-ietf-idr-aigp-14.txt passed IDR Last call in the Fall of 2013. However, during this call the WG chairs did not do a WG Last call on IPR. This is a 2 week Last Call on IPR in draft-ietf-idr-aigp-14.txt This call asks the WG two questions: 1) Do the authors or any WG participants know of any other IPR other than the disclosed IPR below total number of IPR disclosures found: 2 2009-06-30 ID # 1159 "Cisco's Statement of IPR related to draft-ietf-idr-aigp-00" 2009-06-30 ID # 1160 "Cisco's Statement of IPR related to draft-rosen-idr-aigp-00 2) Will you support the draft-ietf-idr-aigp-14.txt with this IPR included. A typical response would be: 1) Know of additional IPR: no/yes 2) Support draft with IRP: no/yes This is a 2 week Last Call on IPR in draft-ietf-idr-aigp-14.txt This does not open the discussion on the draft-ietf-idr-aigp-14.txt. If you wish to send comments on this draft on the list, you are welcomed to do so - but this call is not re-opening the WG LC for content. If you have concerns about this, please send the WG chairs a note. Sue Hares and John Scudder IDR WG chairs ------=_NextPart_000_01A2_01CF0CCB.59A71410 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Draft-ietf-idr-aigp-14.txt passed IDR Last call in the Fall of = 2013.  However, during this call the WG chairs did not do a WG Last = call on IPR. 

 

This is a 2 = week Last Call on IPR in draft-ietf-idr-aigp-14.txt =

 

This call = asks the WG two questions:

 

1)  Do the authors or any WG = participants know of any other IPR other than the disclosed IPR = below

 

total = number of IPR disclosures found: = 2

2009-06-30

ID # = 1159

"Cisco's Statement = of IPR related to = draft-ietf-idr-aigp-00"

2009-06-30

ID # = 1160

"Cisco's Statement = of IPR related to = draft-rosen-idr-aigp-00

 

2)  Will you support the = draft-ietf-idr-aigp-14.txt with this IPR included. =

 

A typical = response would be:

1)  Know of additional IPR: = no/yes

2)  Support draft with IRP: no/yes =

 

 

This is a 2 week Last Call on IPR in = draft-ietf-idr-aigp-14.txt

 

This does not open the discussion on = the draft-ietf-idr-aigp-14.txt. 

 

If you wish to send comments on this = draft on the list, you are welcomed to do so – but this call is = not re-opening the WG LC for content.  If you have concerns about = this, please send the WG chairs a note.

 

Sue Hares and John = Scudder

IDR WG chairs =

 

------=_NextPart_000_01A2_01CF0CCB.59A71410-- From shares@ndzh.com Wed Jan 8 22:25:01 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A21FB1AD72A for ; Wed, 8 Jan 2014 22:25:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.646 X-Spam-Level: *** X-Spam-Status: No, score=3.646 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYG6LwzB7XbE for ; Wed, 8 Jan 2014 22:25:00 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 676001A1F61 for ; Wed, 8 Jan 2014 22:24:58 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "idr wg" Date: Thu, 9 Jan 2014 01:24:40 -0500 Message-ID: <024e01cf0d03$7a84a4d0$6f8dee70$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_024F_01CF0CD9.91B1D120" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8NArDb5GgR3EuHT+yuatRW88Uylw== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: "'John G. Scudder'" Subject: [Idr] WG LC for X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 06:25:01 -0000 This is a multipart message in MIME format. ------=_NextPart_000_024F_01CF0CD9.91B1D120 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This is a 2 week WG LC for IPR on the following draft: Enhanced Route Refresh Capability for BGP-4 draft-ietf-idr-bgp-enhanced-route-refresh-05.txt The 2 week WG LC starts on 1/9/14 and ends on 1/22/14. The questions are as follows: 1) Do the co-authors or any WG participant know of any IPR on this draft? 2) Do you support the draft-ietf-idr-bgp-enhanced-route-refresh-05.txt For publishing as an RFC? Sample answer: 1) IPR: I do/I do not know of IPR for this draft 2) RFC: Support Comments are always welcome. Sue and John WG chairs ------=_NextPart_000_024F_01CF0CD9.91B1D120 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is a 2 week WG = LC for IPR on the following draft:

 

Enhanced Route = Refresh Capability for BGP-4

draft-ietf-idr-bgp-enhanced-route-refresh-05.txt<= /p>

 

The 2 week WG LC = starts on 1/9/14 and ends on 1/22/14.

 

The questions are = as follows:

 

1)  Do the co-authors = or any WG participant know of any IPR on this draft? =

2)  Do you support the = draft-ietf-idr-bgp-enhanced-route-refresh-05.txt

For publishing as = an RFC?

 

Sample = answer:

1)  IPR: I do/I do not = know of IPR for this draft  

2)  RFC: Support =

 

 

Comments are always = welcome.

 

Sue and = John

WG chairs =

 

 

=

------=_NextPart_000_024F_01CF0CD9.91B1D120-- From shares@ndzh.com Wed Jan 8 22:33:38 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6B61A1F7A for ; Wed, 8 Jan 2014 22:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.346 X-Spam-Level: ** X-Spam-Status: No, score=2.346 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e52OggjXhlXi for ; Wed, 8 Jan 2014 22:33:37 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id BC6FA1A1F61 for ; Wed, 8 Jan 2014 22:33:36 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "idr wg" Date: Thu, 9 Jan 2014 01:33:18 -0500 Message-ID: <026801cf0d04$af4998a0$0ddcc9e0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0269_01CF0CDA.C674C920" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8NBKMrKHMolEg8TF26AxOKep0T6A== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: "'John G. Scudder'" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 06:33:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0269_01CF0CDA.C674C920 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Correcting the header. Sue From: Susan Hares [mailto:shares@ndzh.com] Sent: Thursday, January 09, 2014 1:25 AM To: idr wg (idr@ietf.org) Cc: 'John G. Scudder'; John G. Scudder (jgs@juniper.net) Subject: WG LC for This is a 2 week WG LC for IPR on the following draft: Enhanced Route Refresh Capability for BGP-4 draft-ietf-idr-bgp-enhanced-route-refresh-05.txt The 2 week WG LC starts on 1/9/14 and ends on 1/22/14. The questions are as follows: 1) Do the co-authors or any WG participant know of any IPR on this draft? 2) Do you support the draft-ietf-idr-bgp-enhanced-route-refresh-05.txt For publishing as an RFC? Sample answer: 1) IPR: I do/I do not know of IPR for this draft 2) RFC: Support Comments are always welcome. Sue and John WG chairs ------=_NextPart_000_0269_01CF0CDA.C674C920 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Correcting the header.

Sue =

 

From:= = Susan Hares [mailto:shares@ndzh.com]
Sent: Thursday, January = 09, 2014 1:25 AM
To: idr wg (idr@ietf.org)
Cc: 'John = G. Scudder'; John G. Scudder (jgs@juniper.net)
Subject: WG LC = for

 

This is a 2 week WG = LC for IPR on the following draft:

 

Enhanced Route = Refresh Capability for BGP-4

draft-ietf-idr-bgp-enhanced-route-refresh-05.txt<= /p>

 

The 2 week WG LC = starts on 1/9/14 and ends on 1/22/14.

 

The questions are = as follows:

 

1)  Do the co-authors = or any WG participant know of any IPR on this draft? =

2)  Do you support the = draft-ietf-idr-bgp-enhanced-route-refresh-05.txt

For publishing as = an RFC?

 

Sample = answer:

1)  IPR: I do/I do not = know of IPR for this draft  

2)  RFC: Support =

 

 

Comments are always = welcome.

 

Sue and = John

WG chairs =

 

 

 

------=_NextPart_000_0269_01CF0CDA.C674C920-- From thomas.mangin@exa-networks.co.uk Thu Jan 9 00:53:16 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 344101AD8CD; Thu, 9 Jan 2014 00:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5arksNuXR4Kb; Thu, 9 Jan 2014 00:53:14 -0800 (PST) Received: from out-7.mail.exa.net.uk (out-5.mail.exa.net.uk [82.219.4.133]) by ietfa.amsl.com (Postfix) with ESMTP id F2EED1ACCE6; Thu, 9 Jan 2014 00:53:13 -0800 (PST) Received: from smtp-3.mail.exa.net.uk (smtp-3.mail.exa.net.uk [82.219.5.3]) by out-7.mail.exa.net.uk (ExaSMTPD) with ESMTP id EEFFEA005E; Thu, 9 Jan 2014 08:53:02 +0000 (GMT) Received: from [10.0.1.2] (office.exa-networks.co.uk [82.219.212.253]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-3.mail.exa.net.uk (ExaSMTPD) with ESMTPS id 8374D6C0047; Thu, 9 Jan 2014 08:53:02 +0000 (GMT) Content-Type: multipart/signed; boundary="Apple-Mail=_8D24CB04-DF8F-402F-BA0F-F330A6F60465"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Mangin In-Reply-To: <026801cf0d04$af4998a0$0ddcc9e0$@ndzh.com> Date: Thu, 9 Jan 2014 08:53:01 +0000 Message-Id: <2DC98731-BE62-47DC-B6E2-169E9B3E3A35@exa-networks.co.uk> References: <026801cf0d04$af4998a0$0ddcc9e0$@ndzh.com> To: idr-bounces@ietf.org X-Mailer: Apple Mail (2.1827) X-Virus-Scanned: clamav-milter 0.97.8 at out-2-2.mail.exa.net.uk X-Virus-Status: Clean Cc: idr wg , "John G. Scudder" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 08:53:16 -0000 --Apple-Mail=_8D24CB04-DF8F-402F-BA0F-F330A6F60465 Content-Type: multipart/alternative; boundary="Apple-Mail=_1643FE64-8FC1-44F9-8C5E-06AB195BC14E" --Apple-Mail=_1643FE64-8FC1-44F9-8C5E-06AB195BC14E Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > Enhanced Route Refresh Capability for BGP-4 > draft-ietf-idr-bgp-enhanced-route-refresh-05.txt > > The questions are as follows: > > 1) Do the co-authors or any WG participant know of any IPR on this draft? > 2) Do you support the draft-ietf-idr-bgp-enhanced-route-refresh-05.txt > For publishing as an RFC? 1) IPR: Clueless 2) RFC: Support Thomas --Apple-Mail=_1643FE64-8FC1-44F9-8C5E-06AB195BC14E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Enhanced Route Refresh Capability for = BGP-4
draft-ietf-idr-bgp-enhanced-route-refresh-05.txt<= /div>
 
The questions are as follows:
 
1)  Do the co-authors or any WG participant = know of any IPR on this draft?
2)  Do you support = the = draft-ietf-idr-bgp-enhanced-route-refresh-05.txt
For publishing as an = RFC?

1) IPR: = Clueless
2) RFC: = Support

Thomas

= --Apple-Mail=_1643FE64-8FC1-44F9-8C5E-06AB195BC14E-- --Apple-Mail=_8D24CB04-DF8F-402F-BA0F-F330A6F60465 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlLOY20ACgkQA/52wvuLgaFt8ACeOKTwz9eYe5GTLWzgvijuoSnT 5WkAn3wP/VbUJHsYhoehPP7+8CRI/yOn =TBoq -----END PGP SIGNATURE----- --Apple-Mail=_8D24CB04-DF8F-402F-BA0F-F330A6F60465-- From erosen@cisco.com Thu Jan 9 06:49:32 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 466B31AE394 for ; Thu, 9 Jan 2014 06:49:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.039 X-Spam-Level: X-Spam-Status: No, score=-15.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCJNuFGKTIMu for ; Thu, 9 Jan 2014 06:49:29 -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 A028B1AE351 for ; Thu, 9 Jan 2014 06:49:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=66; q=dns/txt; s=iport; t=1389278960; x=1390488560; h=from:to:cc:subject:in-reply-to:reply-to:date:message-id; bh=MSl5fn8Pr2ALJHqRmGDe7i6/zvRgXOjhcmjJIE6BPn0=; b=gG0WAH6JZI9j329mDBzz+4CysAnk1JPvdVzr+zOcPJn28g5fU7M/EQDM UnAMX1tby+XpWeGgydY33FNkVBUcX6Hlh/Ji8k01peU02fGd+a3bePb8c /M9MruAOqqpkCuJwZcPZTq06vPuw1lbiQXnV7/ftdPDfPeGeMmboCbSd/ A=; X-IronPort-AV: E=Sophos;i="4.95,631,1384300800"; d="scan'208";a="102427973" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 09 Jan 2014 14:49:18 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s09EnHAX002799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Jan 2014 14:49:18 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 s09EnHO3015984; Thu, 9 Jan 2014 09:49:17 -0500 From: Eric Rosen To: Susan Hares In-reply-to: Your message of Wed, 08 Jan 2014 23:42:52 -0500. <01a101cf0cf5$42797290$c76c57b0$@ndzh.com> Date: Thu, 09 Jan 2014 09:49:17 -0500 Message-ID: <15983.1389278957@erosen-linux> Cc: idr wg , erosen@cisco.com, draft-ietf-idr-aigp@tools.ietf.org Subject: Re: [Idr] IPR on draft-ietf-idr-aigp-14.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jan 2014 14:49:32 -0000 1) Know of additional IPR: no 2) Support draft with IPR: yes From ju1738@att.com Thu Jan 9 07:14:32 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE7721AD9AE for ; Thu, 9 Jan 2014 07:14:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qX9ruICKolPY for ; Thu, 9 Jan 2014 07:14:31 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id E6F3C1ACC81 for ; Thu, 9 Jan 2014 07:14:30 -0800 (PST) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id dccbec25.2afc786e6940.6164811.00-2480.17330329.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 09 Jan 2014 15:14:21 +0000 (UTC) X-MXL-Hash: 52cebccd2af38e0f-549e11394369dd363817cb99c960b2526673a41f Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 49cbec25.0.6164260.00-2398.17328771.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 09 Jan 2014 15:13:39 +0000 (UTC) X-MXL-Hash: 52cebca3270029f8-730ca180d669f25f77f78b558b618e489dd6f1e4 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s09FDMEf030639; Thu, 9 Jan 2014 10:13:23 -0500 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s09FDCtF030428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Jan 2014 10:13:17 -0500 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (MISOUT7MSGHUB9F.itservices.sbc.com [144.151.223.71]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Thu, 9 Jan 2014 15:13:05 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.03.0174.001; Thu, 9 Jan 2014 10:13:05 -0500 From: "UTTARO, JAMES" To: "erosen@cisco.com" , Susan Hares Thread-Topic: [Idr] IPR on draft-ietf-idr-aigp-14.txt Thread-Index: AQHPDUoe3eF8Heszgkyr26qze1nh7Zp8f/Yg Date: Thu, 9 Jan 2014 15:13:04 +0000 Message-ID: References: Your message of Wed, 08 Jan 2014 23:42:52 -0500. <01a101cf0cf5$42797290$c76c57b0$@ndzh.com> <15983.1389278957@erosen-linux> In-Reply-To: <15983.1389278957@erosen-linux> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.46.215] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=GNu/5JxK c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=mkKMvwBVMGYA:10 a=ofMgfj31e3cA:10 a=suDlmX-ZRDYA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=KxQVieMlnG0A:10 a=48vgC7mUAAAA:8 a=AUd_NHdVAAAA:8] X-AnalysisOut: [ a=WetjbuL7mWCJRwz-x9MA:9 a=CjuIK1q_8ugA:10 a=rKrVYePj7rwA] X-AnalysisOut: [:10 a=lZB815dzVvQA:10 a=JfD0Fch1gWkA:10 a=EfvkLak-4BsA:10 ] X-AnalysisOut: [a=QANDRkAVnAcA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Cc: idr wg , "draft-ietf-idr-aigp@tools.ietf.org" Subject: Re: [Idr] IPR on draft-ietf-idr-aigp-14.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 15:14:33 -0000 +1 Jim Uttaro -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Eric Rosen Sent: Thursday, January 09, 2014 9:49 AM To: Susan Hares Cc: idr wg; erosen@cisco.com; draft-ietf-idr-aigp@tools.ietf.org Subject: Re: [Idr] IPR on draft-ietf-idr-aigp-14.txt 1) Know of additional IPR: no 2) Support draft with IPR: yes=20 _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From thomas.mangin@exa-networks.co.uk Thu Jan 9 07:19:48 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 140971AE386; Thu, 9 Jan 2014 07:19:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJR5Gc9Kf42v; Thu, 9 Jan 2014 07:19:45 -0800 (PST) Received: from out-7.mail.exa.net.uk (out-5.mail.exa.net.uk [82.219.4.133]) by ietfa.amsl.com (Postfix) with ESMTP id 59E3C1AE30B; Thu, 9 Jan 2014 07:19:44 -0800 (PST) Received: from smtp-3.mail.exa.net.uk (smtp-3.mail.exa.net.uk [82.219.5.3]) by out-7.mail.exa.net.uk (ExaSMTPD) with ESMTP id 8DB17A0069; Thu, 9 Jan 2014 15:19:34 +0000 (GMT) Received: from [10.0.1.2] (office.exa-networks.co.uk [82.219.212.253]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-3.mail.exa.net.uk (ExaSMTPD) with ESMTPS id 2BEF46C0047; Thu, 9 Jan 2014 15:19:34 +0000 (GMT) Content-Type: multipart/signed; boundary="Apple-Mail=_2B0E9DAF-0683-4C06-9299-C4B880527EC6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Mangin In-Reply-To: <01a101cf0cf5$42797290$c76c57b0$@ndzh.com> Date: Thu, 9 Jan 2014 15:19:33 +0000 Message-Id: <27FC7CD6-E861-4227-9C7D-8B7C4B6B52F6@exa-networks.co.uk> References: <01a101cf0cf5$42797290$c76c57b0$@ndzh.com> To: idr-bounces@ietf.org X-Mailer: Apple Mail (2.1827) X-Virus-Scanned: clamav-milter 0.97.8 at out-2-2.mail.exa.net.uk X-Virus-Status: Clean Cc: idr wg , draft-ietf-idr-aigp@tools.ietf.org Subject: Re: [Idr] IPR on draft-ietf-idr-aigp-14.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 15:19:48 -0000 --Apple-Mail=_2B0E9DAF-0683-4C06-9299-C4B880527EC6 Content-Type: multipart/alternative; boundary="Apple-Mail=_4A556CB5-2D0C-420F-94EE-10DC659D1EF4" --Apple-Mail=_4A556CB5-2D0C-420F-94EE-10DC659D1EF4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 9 Jan 2014, at 04:42, Susan Hares wrote: > This is a 2 week Last Call on IPR in draft-ietf-idr-aigp-14.txt > =20 > This call asks the WG two questions: > =20 > 1) Do the authors or any WG participants know of any other IPR other = than the disclosed IPR below > =20 > total number of IPR disclosures found: 2 > 2009-06-30 > ID # 1159 > "Cisco's Statement of IPR related to draft-ietf-idr-aigp-00" > 2009-06-30 > ID # 1160 > "Cisco's Statement of IPR related to draft-rosen-idr-aigp-00 > =20 > 2) Will you support the draft-ietf-idr-aigp-14.txt with this IPR = included. 1) Still clueless 2) Support Thomas --Apple-Mail=_4A556CB5-2D0C-420F-94EE-10DC659D1EF4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On 9 = Jan 2014, at 04:42, Susan Hares <shares@ndzh.com> = wrote:

 This is a 2 week = Last Call on IPR in draft-ietf-idr-aigp-14.txt
 
This call asks the WG two = questions:
 
1)  Do the authors or any WG = participants know of any other IPR other than the disclosed IPR = below
 
 
2)  Will you support the = draft-ietf-idr-aigp-14.txt with this IPR = included.

1= ) Still clueless
2) = Support

Thomas


= --Apple-Mail=_4A556CB5-2D0C-420F-94EE-10DC659D1EF4-- --Apple-Mail=_2B0E9DAF-0683-4C06-9299-C4B880527EC6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlLOvgUACgkQA/52wvuLgaFulQCgxc48HCYdwUAiaDVPxkTXTzD0 F+AAn2r4VKTSma/DJjuj642xqH60jiOO =4jP7 -----END PGP SIGNATURE----- --Apple-Mail=_2B0E9DAF-0683-4C06-9299-C4B880527EC6-- From shares@ndzh.com Thu Jan 9 07:35:31 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 742941AE32D for ; Thu, 9 Jan 2014 07:35:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.845 X-Spam-Level: ** X-Spam-Status: No, score=2.845 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id keGVr51TAuOK for ; Thu, 9 Jan 2014 07:35:30 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id D318D1AE30B for ; Thu, 9 Jan 2014 07:35:29 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "idr wg" Date: Thu, 9 Jan 2014 10:35:16 -0500 Message-ID: <035201cf0d50$65cbbef0$31633cd0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0353_01CF0D26.7CF7D9D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8NUGUcV9wGRG4eS5qk8rMSu5JkuQ== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: draft-dong-idr-te-lsp-distribution@tools.ietf.org Subject: [Idr] WG Adoption call for draft-dong-idr-te-lsp-distribution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 15:35:31 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0353_01CF0D26.7CF7D9D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit IDR WG: This is to give a 2 week Call for adoption of: Distribution of MPLS Traffic Engineering (TE) LSP State using BGP draft-dong-idr-te-lsp-distribution-04 https://datatracker.ietf.org/doc/draft-dong-idr-te-lsp-distribution/ WG 2 week calls begins 1/9/14 and ends 1/22/14 Technical description: This document describes a mechanism to collect the Traffic Engineering (TE) LSP information using BGP. Such information can be used by external components for path re-optimization, service placement and network visualization. Sue and John IDR co-chairs ------=_NextPart_000_0353_01CF0D26.7CF7D9D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IDR = WG:

 

This is to give a 2 = week Call for adoption of:

 

Distribution of MPLS = Traffic Engineering (TE) LSP State using BGP

draft-dong-idr-te-lsp-distribution-04

 

https://datatracker.ietf.org/doc/draft-dong-idr-te-lsp-distribution/=

 

WG 2 week calls = begins 1/9/14 and ends 1/22/14

 

Technical = description:

This document = describes a mechanism to collect the Traffic Engineering (TE) LSP = information using BGP.  Such information can be used by external = components for path re-optimization, service placement and network = visualization.

 

 

Sue and John =

IDR co-chairs =

 

------=_NextPart_000_0353_01CF0D26.7CF7D9D0-- From jakob.heitz@ericsson.com Thu Jan 9 09:21:39 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 372FB1AE456 for ; Thu, 9 Jan 2014 09:21:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTsO4hUv03Y5 for ; Thu, 9 Jan 2014 09:21:37 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id B2F151AE432 for ; Thu, 9 Jan 2014 09:21:36 -0800 (PST) X-AuditID: c6180641-b7fbd8e0000011cc-13-52ceda96a2b9 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id C5.47.04556.69ADEC25; Thu, 9 Jan 2014 18:21:26 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0347.000; Thu, 9 Jan 2014 12:21:25 -0500 From: Jakob Heitz To: Susan Hares Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: Ac8NBKMrKHMolEg8TF26AxOKep0T6AAWpYnF Date: Thu, 9 Jan 2014 17:21:25 +0000 Message-ID: References: <026801cf0d04$af4998a0$0ddcc9e0$@ndzh.com> In-Reply-To: <026801cf0d04$af4998a0$0ddcc9e0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_AF28FD53FEBE429182CAEAAA5B7893A8ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyuXSPn+60W+eCDPY80LF4dfsZk8XG/zvY Lf68ecXiwOyxpPs9k8eSJT+ZPGa/vs4awBzFZZOSmpNZllqkb5fAlbHo1AamgjsJFW/+7WJu YDwQ1sXIySEhYCIx7fs8FghbTOLCvfVsXYxcHEICRxglzn84zAjhLGOU2Hf2NhtIFZuAjsS3 613MILaIgKLEkavr2EFsZgFLiWfHv4LVCAu4SbyatJwdosZdouXHJKh6I4lV934xgtgsAioS N85+BtvMK2Av0bv0MiuILSRgJrH8y0OwGk4Bc4nLx06A9TICXff91BomiF3iEreezGeCuFpA Ysme88wQtqjEy8f/WCFqkiXOtv5jg5gvKHFy5hOWCYwis5C0z0JSNgtJGURcR2LB7k9sELa2 xLKFr5lh7DMHHjMhiy9gZF/FyFFanFqWm25kuIkRGFPHJNgcdzAu+GR5iFGag0VJnPfLW+cg IYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYx6T5vvlHjN+ep5fje3/Pq2Uwx8kw5daEhbc/ZX yIkt3+/w72sJWJ6hFWNteuXbwo7kHQECMzxOPX03+b2x2tkerQ5JoQ+qMeK5kyIOuoTd8Fu0 omYl5zTBna1Sx/7M9zPmXNif0ZMfaWFx8Ytb1fk3UZzK0+OC1avfSR/bvSh7x9prq6y14rYo sRRnJBpqMRcVJwIArM0nH3cCAAA= Cc: idr wg , "John G. Scudder" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 17:21:39 -0000 --_000_AF28FD53FEBE429182CAEAAA5B7893A8ericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. No knowledge of IPR. -- Jakob Heitz. On Jan 8, 2014, at 10:33 PM, "Susan Hares" > wrote: Correcting the header. Sue From: Susan Hares [mailto:shares@ndzh.com] Sent: Thursday, January 09, 2014 1:25 AM To: idr wg (idr@ietf.org) Cc: 'John G. Scudder'; John G. Scudder (jgs@juniper.net) Subject: WG LC for This is a 2 week WG LC for IPR on the following draft: Enhanced Route Refresh Capability for BGP-4 draft-ietf-idr-bgp-enhanced-route-refresh-05.txt The 2 week WG LC starts on 1/9/14 and ends on 1/22/14. The questions are as follows: 1) Do the co-authors or any WG participant know of any IPR on this draft? 2) Do you support the draft-ietf-idr-bgp-enhanced-route-refresh-05.txt For publishing as an RFC? Sample answer: 1) IPR: I do/I do not know of IPR for this draft 2) RFC: Support Comments are always welcome. Sue and John WG chairs _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_AF28FD53FEBE429182CAEAAA5B7893A8ericssoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Support.
No knowledge of IPR.

--
Jakob Heitz.


On Jan 8, 2014, at 10:33 PM, "Susan Hares" <shares@ndzh.com> wrote:

Correcting the header.=

Sue =

 

From: Susan Ha= res [mailto:shares@ndzh.com]
Sent: Thursday, January 09, 2014 1:25 AM
To: idr wg (idr@ietf.org)
Cc: 'John G. Scudder'; John G. Scudder (jgs@juniper.net)
Subject: WG LC for

 

This is a 2 week WG LC for IPR on the following draft:

 

Enhanced Route Refresh Capabi= lity for BGP-4

draft-ietf-idr-bgp-enhanced-route-refresh-05.txt

 

The 2 week WG LC starts on 1/9/14 and ends on 1/22/14.

 

The questions are as follows:

 

1)  Do the co-authors or any WG participant know o= f any IPR on this draft?

2)  Do you support the draft-ietf-idr-bgp-enhanced= -route-refresh-05.txt

For publishing as an RFC?

 

Sample answer:

1)  IPR: I do/I do not know of IPR for this draft =  

2)  RFC: Support

 

 

Comments are always welcome.

 

Sue and John

WG chairs

 

 

 

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.iet= f.org/mailman/listinfo/idr
--_000_AF28FD53FEBE429182CAEAAA5B7893A8ericssoncom_-- From keyupate@cisco.com Thu Jan 9 09:29:47 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 170661AE4C5 for ; Thu, 9 Jan 2014 09:29:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.038 X-Spam-Level: X-Spam-Status: No, score=-10.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnjOB6bK1Fl5 for ; Thu, 9 Jan 2014 09:29:44 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1A91AE454 for ; Thu, 9 Jan 2014 09:29:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14170; q=dns/txt; s=iport; t=1389288575; x=1390498175; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=l7ldcyZEBAYZkUfOax7YAVDwU7TdplrXI0Cb/mEaGGg=; b=SGdHn0QFn8cEqqDuDK7VIxTZNuEfA5GSSrk0eFSasL9VPh5u765Dy+MH jtSb9XOYXMo0Kn3ag+sHYWVyEew3INao9CKEDuDAkfi4hcoM5vhVbjqQF vIGn2eTO4dU3oxEGDZA6QND8YgL5ZMH1f0CuD7tpzJiY+sOA5hPKuXLHP Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApkFANjbzlKtJV2b/2dsb2JhbABZgkdEOFa5QYESFnSCJQEBAQQBAQEqQQsSAQgOAwMBAQEoLgsUCQgCBAENBYgEDcRoEwSOdA0EBgGENwSYF5IVgy2CKg X-IronPort-AV: E=Sophos;i="4.95,632,1384300800"; d="scan'208,217";a="11713397" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-7.cisco.com with ESMTP; 09 Jan 2014 17:29:34 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s09HTYmV009245 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Jan 2014 17:29:34 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.228]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Thu, 9 Jan 2014 11:29:34 -0600 From: "Keyur Patel (keyupate)" To: Susan Hares , idr wg Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPDWBcWAfgCOU7oEyC3TOvnpnBIg== Date: Thu, 9 Jan 2014 17:29:34 +0000 Message-ID: In-Reply-To: <026801cf0d04$af4998a0$0ddcc9e0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [128.107.158.19] Content-Type: multipart/alternative; boundary="_000_CEF41D335E33Dkeyupateciscocom_" MIME-Version: 1.0 Cc: "'John G. Scudder'" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 17:29:47 -0000 --_000_CEF41D335E33Dkeyupateciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I as a co-author am not aware of any IPR related to the draft. Regards, Keyur From: Susan Hares > Date: Thu, 9 Jan 2014 01:33:18 -0500 To: idr wg > Cc: "'John G. Scudder'" > Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Correcting the header. Sue From: Susan Hares [mailto:shares@ndzh.com] Sent: Thursday, January 09, 2014 1:25 AM To: idr wg (idr@ietf.org) Cc: 'John G. Scudder'; John G. Scudder (jgs@juniper.net) Subject: WG LC for This is a 2 week WG LC for IPR on the following draft: Enhanced Route Refresh Capability for BGP-4 draft-ietf-idr-bgp-enhanced-route-refresh-05.txt The 2 week WG LC starts on 1/9/14 and ends on 1/22/14. The questions are as follows: 1) Do the co-authors or any WG participant know of any IPR on this draft? 2) Do you support the draft-ietf-idr-bgp-enhanced-route-refresh-05.txt For publishing as an RFC? Sample answer: 1) IPR: I do/I do not know of IPR for this draft 2) RFC: Support Comments are always welcome. Sue and John WG chairs _______________________________________________ Idr mailing list Idr@ietf.o= rg https://www.ietf.org/mailman/listinfo/idr --_000_CEF41D335E33Dkeyupateciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
I as a co-author = am not aware of any IPR related to the draft.

Regards,
Keyur

From: Susan Hares <shares@ndzh.com>
Date: Thu, 9 Jan 2014 01:33:18 -050= 0
To: idr wg <idr@ietf.org>
Cc: "'John G. Scudder'" &= lt;jgs@bgp.nu>
Subject: Re: [Idr] WG LC for draft-= ietf-idr-bgp-enhanced-route-refresh

Correcting the header.=

Sue =

 

From: Susan Hares [= mailto:shares@ndzh.com]
Sent: Thursday, January 09, 2014 1:25 AM
To: idr wg (idr@ietf.org)
Cc: 'John G. Scudder'; John G. Scudder (jgs@juniper.net)
Subject: WG LC for

 

This is a 2 week WG LC for IPR on the following draft:

 

Enhanced Route Refresh Capability fo= r BGP-4

draft-ietf-idr-bgp-enhanced-route-refresh-05.txt

 

The 2 week WG LC starts on 1/9/14 and ends on 1/22/14.=

 

The questions are as follows:

 

1)  Do the co-authors or any WG participant know of any I= PR on this draft?

2)  Do you support the draft-ietf-idr-bgp-enhanced-route-= refresh-05.txt

For publishing as an RFC?

 

Sample answer:

1)  IPR: I do/I do not know of IPR for this draft  <= o:p>

2)  RFC: Support

 

 

Comments are always welcome.

 

Sue and John

WG chairs

 

 

 

_______________________________________________ Idr mailing list Idr@ietf.org http= s://www.ietf.org/mailman/listinfo/idr --_000_CEF41D335E33Dkeyupateciscocom_-- From rraszuk@gmail.com Thu Jan 9 09:38:12 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A4F1AE4DE for ; Thu, 9 Jan 2014 09:38:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0F-AY-5jPHK for ; Thu, 9 Jan 2014 09:38:11 -0800 (PST) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 147E81AE4D9 for ; Thu, 9 Jan 2014 09:38:11 -0800 (PST) Received: by mail-ig0-f176.google.com with SMTP id k19so16690941igc.3 for ; Thu, 09 Jan 2014 09:38:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=mkaYTZWH+gJJy1sAZWxe7nY0BxtAVkQMiAnZ9vE583g=; b=xmJRCH45Ehh474VqhPUngGqVAu6MIt+4OcP/pXlPaFr6cJuBA0b82JCCh5ZZEfxX6h LqqNQMF+FrnJzf7zxmk1xxS0Tv1MU2lZQhZ/C9qt3SjdmPGgx/ud4A5tYM+6jFJHesEN 14/jU96k1MMUeNpzvwWZqPXUmNvmzv27ABFyQxzLN4pdUgCICb+1sE/On+ON0W1kHGJM xULCTpaEMdpUM3kM9rgZMKuS+oNDJcx/NEFKissOaZQ+LvFVy8zMnrzIOWSm02X091Xi xMXxOi/tiDA+KqXsTSDkuj3Fga/DqzpUST661P50BzkgAW46Xu8PbPP9PX6ox1jocEAZ +wXw== MIME-Version: 1.0 X-Received: by 10.50.149.170 with SMTP id ub10mr1597077igb.9.1389289080339; Thu, 09 Jan 2014 09:38:00 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.212.8 with HTTP; Thu, 9 Jan 2014 09:38:00 -0800 (PST) In-Reply-To: <026801cf0d04$af4998a0$0ddcc9e0$@ndzh.com> References: <026801cf0d04$af4998a0$0ddcc9e0$@ndzh.com> Date: Thu, 9 Jan 2014 18:38:00 +0100 X-Google-Sender-Auth: EMXjdDEaCEtIP0y3Y64ICUBNt3s Message-ID: From: Robert Raszuk To: Susan Hares Content-Type: multipart/alternative; boundary=e89a8f3ba3091fc3a104ef8d12ca Cc: idr wg , "John G. Scudder" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 17:38:13 -0000 --e89a8f3ba3091fc3a104ef8d12ca Content-Type: text/plain; charset=ISO-8859-1 1) IPR: do not know of IPR for this draft 2) RFC: Support r. On Thu, Jan 9, 2014 at 7:33 AM, Susan Hares wrote: > Correcting the header. > > Sue > > > > *From:* Susan Hares [mailto:shares@ndzh.com] > *Sent:* Thursday, January 09, 2014 1:25 AM > *To:* idr wg (idr@ietf.org) > *Cc:* 'John G. Scudder'; John G. Scudder (jgs@juniper.net) > *Subject:* WG LC for > > > > This is a 2 week WG LC for IPR on the following draft: > > > > Enhanced Route Refresh Capability for BGP-4 > > draft-ietf-idr-bgp-enhanced-route-refresh-05.txt > > > > The 2 week WG LC starts on 1/9/14 and ends on 1/22/14. > > > > The questions are as follows: > > > > 1) Do the co-authors or any WG participant know of any IPR on this > draft? > > 2) Do you support the draft-ietf-idr-bgp-enhanced-route-refresh-05.txt > > For publishing as an RFC? > > > > Sample answer: > > 1) IPR: I do/I do not know of IPR for this draft > > 2) RFC: Support > > > > > > Comments are always welcome. > > > > Sue and John > > WG chairs > > > > > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --e89a8f3ba3091fc3a104ef8d12ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

1)=A0=A0IPR: =A0do not know of IPR for this draft =A0

2)=A0=A0RFC: Supp= ort

r.

=


On Thu, Jan 9= , 2014 at 7:33 AM, Susan Hares <shares@ndzh.com> wrote:

Correcting= the header.

Sue

=A0

From: Susan Ha= res [mailto:shares@ndz= h.com]
Sent: Thursday, January 09, 2014 1:25 AM
To: idr wg (idr@ietf.org)
Cc: 'John G. Scudder'; John G. Scudder (jgs@juniper.net)
Subject: WG LC for

=A0

This is a 2 week WG LC for= IPR on the following draft:

=A0

<= p class=3D"MsoNormal" style=3D"line-height:14.4pt">Enhanced Route Refresh Capabil= ity for BGP-4

draft-ietf-idr-bgp-enhanced-route-refresh-05.txt=

=A0

The 2 week WG LC starts on 1/9/14 and ends on 1/22/14.<= /u>

=A0

The questions are as follows:

=A0

1)=A0 Do the co-authors or any WG participant know of any IPR o= n this draft?

2)=A0 Do you support the draft-ietf-idr-bgp-enhanced-route-refr= esh-05.txt

For= publishing as an RFC?

=A0<= u>

Sample answer:

1)=A0 I= PR: I do/I do not know of IPR for this draft =A0

2)=A0 RFC: Support

=A0

=A0=

Comments are always welcome.

=A0

Sue and John

WG c= hairs

=A0

= =A0

=A0


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


--e89a8f3ba3091fc3a104ef8d12ca-- From internet-drafts@ietf.org Thu Jan 9 09:41:30 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3101AE4FF; Thu, 9 Jan 2014 09:41:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THDkMZeEm0Dp; Thu, 9 Jan 2014 09:41:25 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD1F1ADF8C; Thu, 9 Jan 2014 09:41:25 -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: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140109174125.6407.98817.idtracker@ietfa.amsl.com> Date: Thu, 09 Jan 2014 09:41:25 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-enhanced-refresh-impl-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 17:41:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : Enhanced Route Refresh Implementation Report Authors : Balaji Venkatachalapathy Keyur Patel Robert Raszuk Prashant P. Hiremath Filename : draft-ietf-idr-enhanced-refresh-impl-00.txt Pages : 5 Date : 2013-12-12 Abstract: This document provides an implementation report for Enhanced Route refresh as defined in draft-ietf-idr-bgp-enhanced-route-refresh. The editor did not verify the accuracy of the information provided by respondents or by any alternative means. The respondents are experts with the implementations they reported on, and their responses are considered authoritative for the implementations for which their responses represent. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-enhanced-refresh-impl/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-enhanced-refresh-impl-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From bill.wu@huawei.com Thu Jan 9 17:08:08 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A183F1AD8EB for ; Thu, 9 Jan 2014 17:08:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53su3RznYx4P for ; Thu, 9 Jan 2014 17:08:05 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 641291A1F55 for ; Thu, 9 Jan 2014 17:08:03 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZU36876; Fri, 10 Jan 2014 01:07:53 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 10 Jan 2014 01:07:15 +0000 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 10 Jan 2014 01:07:52 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Fri, 10 Jan 2014 09:07:45 +0800 From: Qin Wu To: Susan Hares , idr wg Thread-Topic: [Idr] WG Adoption call for draft-dong-idr-te-lsp-distribution Thread-Index: Ac8NUGUcV9wGRG4eS5qk8rMSu5JkuQAT/HQg Date: Fri, 10 Jan 2014 01:07:44 +0000 Message-ID: References: <035201cf0d50$65cbbef0$31633cd0$@ndzh.com> In-Reply-To: <035201cf0d50$65cbbef0$31633cd0$@ndzh.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA43C71212nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-dong-idr-te-lsp-distribution@tools.ietf.org" Subject: Re: [Idr] WG Adoption call for draft-dong-idr-te-lsp-distribution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 01:08:08 -0000 --_000_B8F9A780D330094D99AF023C5877DABA43C71212nkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. Regards! -Qin From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Thursday, January 09, 2014 11:35 PM To: idr wg Cc: draft-dong-idr-te-lsp-distribution@tools.ietf.org Subject: [Idr] WG Adoption call for draft-dong-idr-te-lsp-distribution IDR WG: This is to give a 2 week Call for adoption of: Distribution of MPLS Traffic Engineering (TE) LSP State using BGP draft-dong-idr-te-lsp-distribution-04 https://datatracker.ietf.org/doc/draft-dong-idr-te-lsp-distribution/ WG 2 week calls begins 1/9/14 and ends 1/22/14 Technical description: This document describes a mechanism to collect the Traffic Engineering (TE)= LSP information using BGP. Such information can be used by external compo= nents for path re-optimization, service placement and network visualization= . Sue and John IDR co-chairs --_000_B8F9A780D330094D99AF023C5877DABA43C71212nkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support.

 

Regards!

-Qin=

 

From: Idr [mai= lto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Thursday, January 09, 2014 11:35 PM
To: idr wg
Cc: draft-dong-idr-te-lsp-distribution@tools.ietf.org
Subject: [Idr] WG Adoption call for draft-dong-idr-te-lsp-distributi= on

 

IDR WG:

 

This is to give a 2 week Call for adoption of:

 

Distribution of MPLS Traffic E= ngineering (TE) LSP State using BGP

draft-dong-idr-te-lsp-distribution-04

 

https://datatracker.ietf.org/doc/draft-dong-idr-te-ls= p-distribution/

 

WG 2 week calls begins 1/9/14 and ends 1/22/14

 

Technical description:

This document describes a mech= anism to collect the Traffic Engineering (TE) LSP information using BGP.&nb= sp; Such information can be used by external components for path re-optimization, service placement and network visualization.

 

 

Sue and John

IDR co-chairs

 

--_000_B8F9A780D330094D99AF023C5877DABA43C71212nkgeml501mbschi_-- From xuxiaohu@huawei.com Thu Jan 9 22:44:26 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 223591AD603 for ; Thu, 9 Jan 2014 22:44:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.212 X-Spam-Level: * X-Spam-Status: No, score=1.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXSRIaJWTjj1 for ; Thu, 9 Jan 2014 22:44:23 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7F21AD8E2 for ; Thu, 9 Jan 2014 22:44:22 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCI76056; Fri, 10 Jan 2014 06:44:11 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 10 Jan 2014 06:43:40 +0000 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 10 Jan 2014 06:44:08 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Fri, 10 Jan 2014 14:44:04 +0800 From: Xuxiaohu To: Susan Hares , idr wg Thread-Topic: [Idr] WG Adoption call for draft-dong-idr-te-lsp-distribution Thread-Index: Ac8NUGUcV9wGRG4eS5qk8rMSu5JkuQAfuUGA Date: Fri, 10 Jan 2014 06:44:03 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08243B08@NKGEML512-MBS.china.huawei.com> References: <035201cf0d50$65cbbef0$31633cd0$@ndzh.com> In-Reply-To: <035201cf0d50$65cbbef0$31633cd0$@ndzh.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08243B08NKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-dong-idr-te-lsp-distribution@tools.ietf.org" Subject: [Idr] =?gb2312?b?tPC4tDogIFdHIEFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LWRv?= =?gb2312?b?bmctaWRyLXRlLWxzcC1kaXN0cmlidXRpb24=?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 06:44:26 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08243B08NKGEML512MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 U3VwcG9ydC4NCg0KWGlhb2h1DQoNCreivP7IyzogSWRyIFttYWlsdG86aWRyLWJvdW5jZXNAaWV0 Zi5vcmddILT6se0gU3VzYW4gSGFyZXMNCreiy83KsbzkOiAyMDE0xOox1MI5yNUgMjM6MzUNCsrV vP7IyzogaWRyIHdnDQqzrcvNOiBkcmFmdC1kb25nLWlkci10ZS1sc3AtZGlzdHJpYnV0aW9uQHRv b2xzLmlldGYub3JnDQrW98ziOiBbSWRyXSBXRyBBZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1kb25n LWlkci10ZS1sc3AtZGlzdHJpYnV0aW9uDQoNCklEUiBXRzoNCg0KVGhpcyBpcyB0byBnaXZlIGEg MiB3ZWVrIENhbGwgZm9yIGFkb3B0aW9uIG9mOg0KDQpEaXN0cmlidXRpb24gb2YgTVBMUyBUcmFm ZmljIEVuZ2luZWVyaW5nIChURSkgTFNQIFN0YXRlIHVzaW5nIEJHUA0KZHJhZnQtZG9uZy1pZHIt dGUtbHNwLWRpc3RyaWJ1dGlvbi0wNA0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1kb25nLWlkci10ZS1sc3AtZGlzdHJpYnV0aW9uLw0KDQpXRyAyIHdlZWsgY2FsbHMg YmVnaW5zIDEvOS8xNCBhbmQgZW5kcyAxLzIyLzE0DQoNClRlY2huaWNhbCBkZXNjcmlwdGlvbjoN ClRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgbWVjaGFuaXNtIHRvIGNvbGxlY3QgdGhlIFRyYWZm aWMgRW5naW5lZXJpbmcgKFRFKSBMU1AgaW5mb3JtYXRpb24gdXNpbmcgQkdQLiAgU3VjaCBpbmZv cm1hdGlvbiBjYW4gYmUgdXNlZCBieSBleHRlcm5hbCBjb21wb25lbnRzIGZvciBwYXRoIHJlLW9w dGltaXphdGlvbiwgc2VydmljZSBwbGFjZW1lbnQgYW5kIG5ldHdvcmsgdmlzdWFsaXphdGlvbi4N Cg0KDQpTdWUgYW5kIEpvaG4NCklEUiBjby1jaGFpcnMNCg0K --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08243B08NKGEML512MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Support.

Xiaohu

 

=B7=A2=BC=FE=C8=CB: Idr [mailto:idr-bounc= es@ietf.org] =B4=FA=B1=ED = Susan Hares
=B7=A2=CB=CD= =CA=B1=BC=E4: 2014=C4=EA1=D4=C2<= span lang=3D"EN-US">9=C8=D5 23:35
=CA=D5=BC=FE=C8=CB: idr wg
=B3=AD=CB=CD: draft-dong-idr-te-lsp-distribution@tools.ietf.org
=D6=F7=CC=E2: [Idr] WG Adoption call for draft-dong-idr-te-lsp-distribution<= /span>

 

IDR WG:

 

This is to give a 2 week Call for adoption o= f:

 

Distribution of= MPLS Traffic Engineering (TE) LSP State using BGP

draft-dong-idr-te-lsp-distribution-04

 

https://datatracker.ietf.org/doc/draft= -dong-idr-te-lsp-distribution/

 

WG 2 week calls begins 1/9/14 and ends 1/22/= 14

 

Technical de= scription:

This document d= escribes a mechanism to collect the Traffic Engineering (TE) LSP informatio= n using BGP.  Such information can be used by external components for path re-optimization, service placement and network visuali= zation.

 

 

Sue and John

IDR co-chairs

 

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08243B08NKGEML512MBSchi_-- From christopher.morrow@gmail.com Fri Jan 10 12:17:59 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 574131AE1BD for ; Fri, 10 Jan 2014 12:17:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4rW5o4MN7Hm for ; Fri, 10 Jan 2014 12:17:57 -0800 (PST) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 47B531AE171 for ; Fri, 10 Jan 2014 12:17:57 -0800 (PST) Received: by mail-lb0-f173.google.com with SMTP id y6so1819665lbh.18 for ; Fri, 10 Jan 2014 12:17:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=abOweJ5nIWplJRNwAAGxxpX5W2QUlJvcGvWG7X+bZuI=; b=sk1wLDlgjN5lrDJKKHQRPZowxG+SW1p3yBL4n/5ti4SA6TWwW4zRtE4UeougTkgOpN Xs0ZtfFzKnSjExify4NDHP2hoBWrqkxx4r/X8rsAfmnryQ8RIYuIv81fwl+pQ8aso0U1 E9wxyfuf8sg1ynCuNaBRXKqFTcRR8A2AKlqBtN3LyVi7ummGIe6B5Fs5ac/bhH5pUmsn xG7l137qH1siEqgrlFDqfZYyuLL/9b6yIMjSmg5uUdqXycDXQ8RieAVzTbZUFDOFs3uf OjROVElFMoft+SspKvT30lU/qi7jyRoTmJEIsn6E32HvELRZ6k8u7gzFepRRIxw4ZTV9 jEjg== MIME-Version: 1.0 X-Received: by 10.152.1.5 with SMTP id 5mr4728643lai.20.1389385066593; Fri, 10 Jan 2014 12:17:46 -0800 (PST) Received: by 10.152.37.170 with HTTP; Fri, 10 Jan 2014 12:17:46 -0800 (PST) Date: Fri, 10 Jan 2014 15:17:46 -0500 Message-ID: From: Christopher Morrow To: "idr@ietf.org List" Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Fri, 10 Jan 2014 12:54:38 -0800 Subject: [Idr] Question about draft: draft-ga-idr-as-migration-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 20:17:59 -0000 link to draft: http://trac.tools.ietf.org/id/draft-ga-idr-as-migration-03.txt This doesn't point or ask for new BGP features/functions, why is this in IDR? It sounds/reads/looks like it is 'operations stuff', which would fall into GROW, no? -chris From rraszuk@gmail.com Fri Jan 10 13:22:35 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5C971AE0EC for ; Fri, 10 Jan 2014 13:22:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ht-dMuZhaiOk for ; Fri, 10 Jan 2014 13:22:34 -0800 (PST) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 6790E1AE18C for ; Fri, 10 Jan 2014 13:22:30 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id at1so5640824iec.7 for ; Fri, 10 Jan 2014 13:22:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=HT8YoAG2kdX7J1LRG3ly8V3bNgR5e9k2v48Zih0NLGU=; b=FKHwMy3musAuPSG1cLGbVhOH24hi9V5TwNFgAW4zPW0VYp4cM5fXUtTiVlJYVX2DRZ 8TbZ7uYK2Ir41xLInM567QXDqXg+E2PZLoYxgAbFPiP/Toyeezm4FHBi9iYZge3M1fJr vf6mcsFa6oUT/qF03x5rY1AAE7c8CXgZFygkznXZqylSEh2Y8UlvfnyjQ1l/tc8rHmqV bxPiHMhzWfshvBgT64Ic0Po3U89FSmNIl3BOpi15R0R6Dn1byCIJXQggmF6HIXciUMHm 5rgn2qLb/Go1W0Iambevlyxr0ANYO0XdTrjvj3ooexwaPGkSxPAUMFeym9gI4aUXe9Fl RsDQ== MIME-Version: 1.0 X-Received: by 10.50.20.74 with SMTP id l10mr6038095ige.9.1389388940289; Fri, 10 Jan 2014 13:22:20 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.212.8 with HTTP; Fri, 10 Jan 2014 13:22:20 -0800 (PST) In-Reply-To: References: Date: Fri, 10 Jan 2014 22:22:20 +0100 X-Google-Sender-Auth: 9mTkrKkUxCoNQdY9XUz2tPNZnR0 Message-ID: From: Robert Raszuk To: Christopher Morrow Content-Type: multipart/alternative; boundary=047d7bd752703dac4804efa452e1 Cc: "idr@ietf.org List" Subject: Re: [Idr] Question about draft: draft-ga-idr-as-migration-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 21:22:36 -0000 --047d7bd752703dac4804efa452e1 Content-Type: text/plain; charset=ISO-8859-1 Hi Chris, Well this draft discusses applicability of local-as, no-prepend and replace-as knobs. I would also augment it with a BGP policy function available in some ASes to replace operator's defined arbitrary string in AS_PATH with your own AS which is different then replace-as knob and turns pretty useful in some scenarios. IMO it does belong to IDR as implementations first need to support such knobs in order for operators to discuss its use in GROW. And for that implementors need to understand them. While 3 quoted implementations support it (better or worse :) there are number of other BGP code basis which still do not. While it does not change protocol encoding it does change the RFC behavior of BGP AS_PATH handling so I would recommend to keep it in IDR even from operational perspective. Best, R. On Fri, Jan 10, 2014 at 9:17 PM, Christopher Morrow < christopher.morrow@gmail.com> wrote: > link to draft: > http://trac.tools.ietf.org/id/draft-ga-idr-as-migration-03.txt > > This doesn't point or ask for new BGP features/functions, why is this > in IDR? It sounds/reads/looks like it is 'operations stuff', which > would fall into GROW, no? > > -chris > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --047d7bd752703dac4804efa452e1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Chris,

Well this draft discusses applicability of local-as, no-prepend and replace= -as knobs. I would also augment it with a BGP policy function available in = some ASes to replace operator's defined arbitrary string in AS_PATH wit= h your own AS which is different then replace-as knob and turns pretty usef= ul in some scenarios.=A0

IMO it does belong to IDR as implemen= tations first need to support such knobs in order for operators to discuss = its use in GROW. And for that implementors need to understand them. While 3= quoted implementations support it (better or worse :) there are number of = other BGP code basis which still do not.=A0

While it does not change protocol enc= oding it does change the RFC behavior of BGP AS_PATH handling so I would re= commend to keep it in IDR even from operational perspective.

Best,
R.



On Fri, Jan 10, 2014 at 9:17 PM, Christopher Morrow &l= t;christo= pher.morrow@gmail.com> wrote:
link to draft: http://trac= .tools.ietf.org/id/draft-ga-idr-as-migration-03.txt

This doesn't point or ask for new BGP features/functions, why is this in IDR? It sounds/reads/looks like it is 'operations stuff', which<= br> would fall into GROW, no?

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

--047d7bd752703dac4804efa452e1-- From christopher.morrow@gmail.com Fri Jan 10 13:30:41 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE5951AE1BC for ; Fri, 10 Jan 2014 13:30:41 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2tumnQRm1co for ; Fri, 10 Jan 2014 13:30:39 -0800 (PST) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id D4FEE1AE13F for ; Fri, 10 Jan 2014 13:30:38 -0800 (PST) Received: by mail-la0-f48.google.com with SMTP id n7so3593958lam.21 for ; Fri, 10 Jan 2014 13:30:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to :content-type; bh=rBorteyLeNPg25sfkYtju9fzOImFWJTyLiIEKmr8xX8=; b=U8CUATMDQDF5uaF3n9v5x9SegR3Cpt6q6L3+LoggLePN2WIGvSC0l0LhLa/zBQnVl0 3wVSBvOdYq/XPWaZ6HEn+D7PIztmreTN7O+rtGYS5uRZ/265l1HgrAdEMv4A0RN5iRI+ nwTg+joSy5gRgj0CUVnCgEoYlNRiJfOP9+ShCsSv0tbUofFp4yLXKlWtp/XmURp1dGXS Y/wCa9wF74EZGWv3RrSQc1bbWXENIc1RTZKIrbbY3exMKItPmpYarDzSBp7FUJb3n3pT +uXRgGI8Fa5pHD/SOcIalhMqSttb9rQyG2HlHgu6AyTgtnqBCZA/u3NwWNNEQgPZzjXn pIXQ== X-Received: by 10.152.9.9 with SMTP id v9mr4674409laa.41.1389389428038; Fri, 10 Jan 2014 13:30:28 -0800 (PST) MIME-Version: 1.0 References: From: Christopher Morrow Date: Fri, 10 Jan 2014 21:30:27 +0000 Message-ID: <-4042749855639388205@gmail297201516> To: robert@raszuk.net, idr@ietf.org Content-Type: multipart/alternative; boundary=089e0149512650216a04efa46fa7 Subject: Re: [Idr] Question about draft: draft-ga-idr-as-migration-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 21:30:41 -0000 --089e0149512650216a04efa46fa7 Content-Type: text/plain; charset=ISO-8859-1 On Fri Jan 10 2014 at 4:22:20 PM, Robert Raszuk wrote: > Hi Chris, > > Well this draft discusses applicability of local-as, no-prepend and > replace-as knobs. I > right, vendor specific configuration options, not changes to the bgp protocol itself... I thought. > would also augment it with a BGP policy function available in some ASes to > replace operator's defined arbitrary string in AS_PATH with your own AS > which is different then replace-as knob and turns pretty useful in some > scenarios. > > sure, I'm not saying that the migration document isn't interesting and useful, nor the knobs. > IMO it does belong to IDR as implementations first need to support such > knobs in order for operators to discuss its use in GROW. And for that > implementors need to understand them. While 3 quoted implementations > support it (better or worse :) there are number of other BGP code basis > which still do not. > wait, so now IDR is going to spec implementation knobs? that seems like it's outside of the charter to me... or rather I don't see this in the list of work items or in the generic charter fluff before work items. it seems much more clearly to fit in the grow world view... (not that I want more work in grow, but this just doesn't seem like IDR to me) > > While it does not change protocol encoding it does change the RFC behavior > of BGP AS_PATH handling so I would recommend to keep it in IDR even from > operational perspective. > > I await chair direction. > Best, > R. > > > > On Fri, Jan 10, 2014 at 9:17 PM, Christopher Morrow < > christopher.morrow@gmail.com> wrote: > > link to draft: > http://trac.tools.ietf.org/id/draft-ga-idr-as-migration-03.txt > > This doesn't point or ask for new BGP features/functions, why is this > in IDR? It sounds/reads/looks like it is 'operations stuff', which > would fall into GROW, no? > > -chris > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > > --089e0149512650216a04efa46fa7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri Jan 10 2014 at 4:22:20 PM, Robert Raszuk <robert@raszuk.net> wrote:
Hi Chris,

Well this draft discusses applicability of local-as, no-prepend and replace= -as knobs. I

right, vendor spe= cific configuration options, not changes to the bgp protocol itself... I th= ought.
=A0
would also augment it w= ith a BGP policy function available in some ASes to replace operator's = defined arbitrary string in AS_PATH with your own AS which is different the= n replace-as knob and turns pretty useful in some scenarios.=A0

=

sure, I'm not saying that the mi= gration document isn't interesting and useful, nor the knobs.
=A0
IMO it does belong to IDR as implementations first need to support such kno= bs in order for operators to discuss its use in GROW. And for that implemen= tors need to understand them. While 3 quoted implementations support it (be= tter or worse :) there are number of other BGP code basis which still do no= t.=A0

wait, so now IDR is going to spec im= plementation knobs? that seems like it's outside of the charter to me..= . or rather I don't see this in the list of work items or in the generi= c charter fluff before work items.

it seems much more clearly to fit in the grow world vie= w... (not that I want more work in grow, but this just doesn't seem lik= e IDR to me)

=A0

=
While it d= oes not change protocol encoding it does change the RFC behavior of BGP AS_= PATH handling so I would recommend to keep it in IDR even from operational = perspective.

=

I await chair direction.
= =A0
Best,
R.



On Fri, Jan 10, 201= 4 at 9:17 PM, Christopher Morrow <christopher.morrow@gmail.com<= /a>> wrote:
link to draft: http://trac= .tools.ietf.org/id/draft-ga-idr-as-migration-03.txt

This doesn't point or ask for new BGP features/functions, why is this in IDR? It sounds/reads/looks like it is 'operations stuff', which<= br> would fall into GROW, no?

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

--089e0149512650216a04efa46fa7-- From rraszuk@gmail.com Fri Jan 10 13:35:52 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC4791AE1E2 for ; Fri, 10 Jan 2014 13:35:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVlSahNif19M for ; Fri, 10 Jan 2014 13:35:50 -0800 (PST) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id B7B041AE1F2 for ; Fri, 10 Jan 2014 13:35:50 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id ar20so1594582iec.11 for ; Fri, 10 Jan 2014 13:35:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=/IPbpN3LDOEblUdVXSYyX9otP9ZPcgWMN5gnt38du1o=; b=kWxjj7bsOWEL2UOnFX6Ld7P5zlHkt52hDCq4LUhd1JSl6dybyXAKCzPdkGP9NiV2mF 3ND/EDx7/CdDWx+6bo7PlR4WetkPRFiAjUy4stmlEi3dIBzFSMB6+7dS97FX5gVo/SYh /P5Qx1ykI1kwjvIe26kMeNPtlmp9Ns8shH99QHcN/YLM5vDbjkc+aOytrNMLPci0s3Y3 RLylgPCgoCBOJ9qg1ZOhDQ2LWjSxbnDL4Whmbh5fN+Fp6YJ2cnM1GrwLZ2mhYkqyhIM7 glb6evBBGtzYrlVtvRaRh5r9gqsYcZ/XcDLO5KlyD9DoNR8AE15WQS2XuIgYW91QeApV jUfA== MIME-Version: 1.0 X-Received: by 10.50.97.6 with SMTP id dw6mr5934329igb.21.1389389740683; Fri, 10 Jan 2014 13:35:40 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.212.8 with HTTP; Fri, 10 Jan 2014 13:35:40 -0800 (PST) In-Reply-To: <-4042749855639388205@gmail297201516> References: <-4042749855639388205@gmail297201516> Date: Fri, 10 Jan 2014 22:35:40 +0100 X-Google-Sender-Auth: 1JbO_9hU37QNidCU3-nIjzA_GX4 Message-ID: From: Robert Raszuk To: Christopher Morrow Content-Type: multipart/alternative; boundary=047d7b10ca6bf2b84404efa481bf Cc: idr wg Subject: Re: [Idr] Question about draft: draft-ga-idr-as-migration-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 21:35:53 -0000 --047d7b10ca6bf2b84404efa481bf Content-Type: text/plain; charset=ISO-8859-1 Chris, I am actually fine to see this draft in either groups. After all the audience of both groups is very similar :) But the precedence with IX route servers where we were recommended to split spec into two documents just since it changes default BGP RFC behavior - yet no new protocol extension needed - lead me to believe that this would also fit a bit better to IDR. Best, R. On Fri, Jan 10, 2014 at 10:30 PM, Christopher Morrow < christopher.morrow@gmail.com> wrote: > > > On Fri Jan 10 2014 at 4:22:20 PM, Robert Raszuk wrote: > >> Hi Chris, >> >> Well this draft discusses applicability of local-as, no-prepend and >> replace-as knobs. I >> > > right, vendor specific configuration options, not changes to the bgp > protocol itself... I thought. > > >> would also augment it with a BGP policy function available in some ASes >> to replace operator's defined arbitrary string in AS_PATH with your own AS >> which is different then replace-as knob and turns pretty useful in some >> scenarios. >> >> > sure, I'm not saying that the migration document isn't interesting and > useful, nor the knobs. > > >> IMO it does belong to IDR as implementations first need to support such >> knobs in order for operators to discuss its use in GROW. And for that >> implementors need to understand them. While 3 quoted implementations >> support it (better or worse :) there are number of other BGP code basis >> which still do not. >> > > wait, so now IDR is going to spec implementation knobs? that seems like > it's outside of the charter to me... or rather I don't see this in the list > of work items or in the generic charter fluff before work items. > > it seems much more clearly to fit in the grow world view... (not that I > want more work in grow, but this just doesn't seem like IDR to me) > > > >> >> While it does not change protocol encoding it does change the RFC >> behavior of BGP AS_PATH handling so I would recommend to keep it in IDR >> even from operational perspective. >> >> > I await chair direction. > > >> Best, >> R. >> >> >> >> On Fri, Jan 10, 2014 at 9:17 PM, Christopher Morrow < >> christopher.morrow@gmail.com> wrote: >> >> link to draft: >> http://trac.tools.ietf.org/id/draft-ga-idr-as-migration-03.txt >> >> This doesn't point or ask for new BGP features/functions, why is this >> in IDR? It sounds/reads/looks like it is 'operations stuff', which >> would fall into GROW, no? >> >> -chris >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> >> >> --047d7b10ca6bf2b84404efa481bf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Chris,

I am actually fine to see this draft in either groups. After all the audien= ce of both groups is very similar :)

But the precedence with IX route servers where we were recommended to split= spec into two documents just since it changes default BGP RFC behavior - y= et no new protocol extension needed - lead me to believe that this would al= so fit a bit better to IDR.=A0

Best,
R.



On Fri, Jan 10, 2014 at 10:30 PM, Christopher Morr= ow <christopher.morrow@gmail.com> wrote:


On Fri Jan 10= 2014 at 4:22:20 PM, Robert Raszuk <robert@raszuk.net> wrote:
Hi Chris,

Well this draft discusses applicability of local-as, no-prepend and replace= -as knobs. I

right, vend= or specific configuration options, not changes to the bgp protocol itself..= . I thought.
=A0
would also augment it w= ith a BGP policy function available in some ASes to replace operator's = defined arbitrary string in AS_PATH with your own AS which is different the= n replace-as knob and turns pretty useful in some scenarios.=A0

=

sure, I'm not saying that = the migration document isn't interesting and useful, nor the knobs.
=A0
IMO it does belong to IDR as implementations first need to support such kno= bs in order for operators to discuss its use in GROW. And for that implemen= tors need to understand them. While 3 quoted implementations support it (be= tter or worse :) there are number of other BGP code basis which still do no= t.=A0

wait, so now IDR is going to s= pec implementation knobs? that seems like it's outside of the charter t= o me... or rather I don't see this in the list of work items or in the = generic charter fluff before work items.

it seems much more clearly to fit in the grow world vie= w... (not that I want more work in grow, but this just doesn't seem lik= e IDR to me)

=A0

=
While it d= oes not change protocol encoding it does change the RFC behavior of BGP AS_= PATH handling so I would recommend to keep it in IDR even from operational = perspective.

=

I await chair direction.
=
=A0
Best,
R.



On Fri, Jan 10, 201= 4 at 9:17 PM, Christopher Morrow <christopher.morrow@gmail.com<= /a>> wrote:
link to draft: http://trac= .tools.ietf.org/id/draft-ga-idr-as-migration-03.txt

This doesn't point or ask for new BGP features/functions, why is this in IDR? It sounds/reads/looks like it is 'operations stuff', which<= br> would fall into GROW, no?

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


--047d7b10ca6bf2b84404efa481bf-- From randy@psg.com Fri Jan 10 17:18:26 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C31FC1ACB4E for ; Fri, 10 Jan 2014 17:18:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Qj4kS3oUfd6 for ; Fri, 10 Jan 2014 17:18:25 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 337081A1F76 for ; Fri, 10 Jan 2014 17:18:25 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1W1nDJ-0005fF-1W; Sat, 11 Jan 2014 01:18:13 +0000 Date: Sat, 11 Jan 2014 10:18:11 +0900 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: <-4042749855639388205@gmail297201516> References: <-4042749855639388205@gmail297201516> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Sat_Jan_11_10:18:08_2014-1"; micalg=pgp-sha512; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Cc: idr wg , Robert Raszuk Subject: Re: [Idr] Question about draft: draft-ga-idr-as-migration-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2014 01:18:27 -0000 --pgp-sign-Multipart_Sat_Jan_11_10:18:08_2014-1 Content-Type: text/plain; charset=US-ASCII >> Well this draft discusses applicability of local-as, no-prepend and >> replace-as knobs. I > > right, vendor specific configuration options, not changes to the bgp > protocol itself... I thought. > >> would also augment it with a BGP policy function available in some ASes to >> replace operator's defined arbitrary string in AS_PATH with your own AS >> which is different then replace-as knob and turns pretty useful in some >> scenarios. > > sure, I'm not saying that the migration document isn't interesting and > useful, nor the knobs. > >> IMO it does belong to IDR as implementations first need to support such >> knobs in order for operators to discuss its use in GROW. And for that >> implementors need to understand them. While 3 quoted implementations >> support it (better or worse :) there are number of other BGP code basis >> which still do not. > > wait, so now IDR is going to spec implementation knobs? that seems like > it's outside of the charter to me... or rather I don't see this in the list > of work items or in the generic charter fluff before work items. > > it seems much more clearly to fit in the grow world view... (not that I > want more work in grow, but this just doesn't seem like IDR to randy, who thinks we really need a wg called (and doing) shrink --pgp-sign-Multipart_Sat_Jan_11_10:18:08_2014-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAABCgAGBQJS0JvTAAoJEMzMBey4OgLtSPMIAItVGOydcEyNLmWhMW2/Vdzk CBweqGDAO5/Bl9gxJEQwWKS7eu9zs0GjP1a4U29lVu8hJiN+7SlL+lmaxp1XtgFf R609P94y5qyeu1h/QSERbdfofpTcTid5OAwePagtSCTHDVfWLmRbYO8kW1RDWel0 CQLsjzo7LQ12qMaQTKRv2YUfitX4oVd3g9VFzC13+NMSPg38qFn0dJ5kwoMKSbtN hGpLu5sMze2L1bBHsRoLpZK13qJdt8N8ewNHJrVzAztDJCBYaU7Dn5jjCxqldZiP ZyJLfARxINo6Zx/2guiYq2CngiaO/rIEkT19WXqi8caQ5pvyo0hb2icPf8PNnEU= =nmYi -----END PGP SIGNATURE----- --pgp-sign-Multipart_Sat_Jan_11_10:18:08_2014-1-- From internet-drafts@ietf.org Sun Jan 12 18:30:14 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5F11AD8F9; Sun, 12 Jan 2014 18:30:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEx3zyk6_r6K; Sun, 12 Jan 2014 18:30:12 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB8D1AD627; Sun, 12 Jan 2014 18:30: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: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140113023012.3523.58694.idtracker@ietfa.amsl.com> Date: Sun, 12 Jan 2014 18:30:12 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-te-pm-bgp-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 02:30:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : BGP attribute for North-Bound Distribution of Tra= ffic Engineering (TE) performance Metrics Authors : Qin Wu Danhua Wang Stefano Previdi Hannes Gredler Saikat Ray Filename : draft-ietf-idr-te-pm-bgp-00.txt Pages : 15 Date : 2014-01-09 Abstract: In order to populate network performance information like link latency, latency variation, packet loss and bandwidth into Traffic Engineering Database(TED) and ALTO server, this document describes extensions to BGP protocol, that can be used to distribute network performance information (such as link delay, delay variation, packet loss, residual bandwidth, available bandwidth and utilized bandwidth ). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-te-pm-bgp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-te-pm-bgp-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From bhavani@cisco.com Mon Jan 13 11:05:01 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B46EC1ADF9A for ; Mon, 13 Jan 2014 11:05:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.038 X-Spam-Level: X-Spam-Status: No, score=-15.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1D-oyVoc65LB for ; Mon, 13 Jan 2014 11:05:00 -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 C30D51ADF93 for ; Mon, 13 Jan 2014 11:04:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13355; q=dns/txt; s=iport; t=1389639889; x=1390849489; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=OrAlnDOu57cLT8ROibQaVEDtnLfsBRkzbXYVLv+/OcE=; b=L8F4yHF7gBoTqvvlBKEefAdWKCd5gVvtCtuCbsyu98U1aavr9nnXty8t VSIHZCtK9cYZF4MVI3DheyR62dzzk7dPKYFIQpohLq4LPcpudvyn2+/y0 lKa4fQHrJ8QwhuB7A+U6zDB0+ZLhdlOTrPGr019JaQHmXOIpUcQOAdwXc Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsFAGw41FKrRDoI/2dsb2JhbABagkdEOLpIgRgWdIIlAQEBBAEBASpBChELEQQBAQEJFggHCQMCAQIBFR8JCBMGAgEBh38OxG8TBI8NARaEIQSJQ45UhkWLUINOGw X-IronPort-AV: E=Sophos;i="4.95,654,1384300800"; d="scan'208,217";a="102866970" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 13 Jan 2014 19:04:47 +0000 Received: from [10.154.209.254] ([10.154.209.254]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0DJ4k9o017636 for ; Mon, 13 Jan 2014 19:04:46 GMT Message-ID: <52D438CE.8060802@cisco.com> Date: Mon, 13 Jan 2014 11:04:46 -0800 From: Bhavani Parise User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: idr@ietf.org References: <026801cf0d04$af4998a0$0ddcc9e0$@ndzh.com> In-Reply-To: <026801cf0d04$af4998a0$0ddcc9e0$@ndzh.com> Content-Type: multipart/alternative; boundary="------------010702050002060602030301" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 19:05:01 -0000 This is a multi-part message in MIME format. --------------010702050002060602030301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit RFC:support regards, Bhavani On 1/8/14 10:33 PM, Susan Hares wrote: > > Correcting the header. > > Sue > > *From:*Susan Hares [mailto:shares@ndzh.com] > *Sent:* Thursday, January 09, 2014 1:25 AM > *To:* idr wg (idr@ietf.org) > *Cc:* 'John G. Scudder'; John G. Scudder (jgs@juniper.net) > *Subject:* WG LC for > > This is a 2 week WG LC for IPR on the following draft: > > Enhanced Route Refresh Capability for BGP-4 > > draft-ietf-idr-bgp-enhanced-route-refresh-05.txt > > The 2 week WG LC starts on 1/9/14 and ends on 1/22/14. > > The questions are as follows: > > 1)Do the co-authors or any WG participant know of any IPR on this draft? > > 2)Do you support the draft-ietf-idr-bgp-enhanced-route-refresh-05.txt > > For publishing as an RFC? > > Sample answer: > > 1)IPR: I do/I do not know of IPR for this draft > > 2)RFC: Support > > Comments are always welcome. > > Sue and John > > WG chairs > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --------------010702050002060602030301 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

RFC:support

regards,
Bhavani

On 1/8/14 10:33 PM, Susan Hares wrote:

Correcting the header.

Sue

 

From: Susan Hares [mailto:shares@ndzh.com]
Sent: Thursday, January 09, 2014 1:25 AM
To: idr wg (idr@ietf.org)
Cc: 'John G. Scudder'; John G. Scudder (jgs@juniper.net)
Subject: WG LC for

 

This is a 2 week WG LC for IPR on the following draft:

 

Enhanced Route Refresh Capability for BGP-4

draft-ietf-idr-bgp-enhanced-route-refresh-05.txt

 

The 2 week WG LC starts on 1/9/14 and ends on 1/22/14.

 

The questions are as follows:

 

1)  Do the co-authors or any WG participant know of any IPR on this draft?

2)  Do you support the draft-ietf-idr-bgp-enhanced-route-refresh-05.txt

For publishing as an RFC?

 

Sample answer:

1)  IPR: I do/I do not know of IPR for this draft  

2)  RFC: Support

 

 

Comments are always welcome.

 

Sue and John

WG chairs

 

 

 



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

--------------010702050002060602030301-- From shares@ndzh.com Mon Jan 13 12:13:08 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E8F1ADF97 for ; Mon, 13 Jan 2014 12:13:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.845 X-Spam-Level: ** X-Spam-Status: No, score=2.845 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqJ5qPSGt7O6 for ; Mon, 13 Jan 2014 12:13:06 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id AFA5B1ADF89 for ; Mon, 13 Jan 2014 12:13:06 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "idr wg" Date: Mon, 13 Jan 2014 15:12:43 -0500 Message-ID: <008301cf109b$d20238d0$7606aa70$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0084_01CF1071.E92CF420" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8Qm6X9CPSHvhNMTja8YJbekEFqOw== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: Jon.Mitchell@microsoft.com, "'John G. Scudder'" Subject: [Idr] WG LC for X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 20:13:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0084_01CF1071.E92CF420 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This is to start a 2 week last call on Reservation of Last Autonomous System (AS) Numbers http://tools.ietf.org/html/draft-ietf-idr-last-as-reservation-01 This working group last all we start today and go to 1/27/14. We look forward to active discussion. Email should include: Support: yes/no Thank you, Sue and John Co-chairs ------=_NextPart_000_0084_01CF1071.E92CF420 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is to start a 2 week last call on =

Reservation of Last Autonomous System (AS) = Numbers

http://tools.ietf.org/html/draft-ietf-idr-last-as-reservation-01

This working group last all we start today and go to = 1/27/14. 

We look forward to active discussion.  Email = should include:

Support: yes/no

Thank you,

Sue and John

Co-chairs

------=_NextPart_000_0084_01CF1071.E92CF420-- From shares@ndzh.com Mon Jan 13 12:14:19 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 643AF1ADFAE for ; Mon, 13 Jan 2014 12:14:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.845 X-Spam-Level: ** X-Spam-Status: No, score=2.845 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqUmuL2WXqwZ for ; Mon, 13 Jan 2014 12:14:18 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 545581ADF89 for ; Mon, 13 Jan 2014 12:14:18 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'idr wg'" Date: Mon, 13 Jan 2014 15:14:00 -0500 Message-ID: <009601cf109b$ffc83580$ff58a080$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0097_01CF1072.16F317E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8Qm/8mv2f4+St0QpSZMG2aCSFWXg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: "'John G. Scudder'" , Jon.Mitchell@microsoft.com Subject: [Idr] WG LC for draft-ietf-idr-last-as-reservation-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 20:14:19 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0097_01CF1072.16F317E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit [re-sending - so web-site indexing works] This is to start a 2 week last call on Reservation of Last Autonomous System (AS) Numbers http://tools.ietf.org/html/draft-ietf-idr-last-as-reservation-01 This working group last all we start today and go to 1/27/14. We look forward to active discussion. Email should include: Support: yes/no Thank you, Sue and John Co-chairs ------=_NextPart_000_0097_01CF1072.16F317E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[re-sending – so web-site indexing works] =

This is to start a 2 week last call on =

Reservation of Last Autonomous System (AS) = Numbers

http://tools.ietf.org/html/draft-ietf-idr-last-as-reservation-01

This working group last all we start today and go to = 1/27/14. 

We look forward to active discussion.  Email = should include:

Support: yes/no

Thank you,

Sue and John

Co-chairs

------=_NextPart_000_0097_01CF1072.16F317E0-- From rraszuk@gmail.com Mon Jan 13 12:15:19 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1866B1AE00A for ; Mon, 13 Jan 2014 12:15:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v_bOij4R-UsC for ; Mon, 13 Jan 2014 12:15:17 -0800 (PST) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 85F521ADF89 for ; Mon, 13 Jan 2014 12:15:17 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id ar20so4373585iec.39 for ; Mon, 13 Jan 2014 12:15:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=o2Ia2xlj5rb/vGbTSMaV7grgxuDnl+ci5V4jSNUOd3Q=; b=HKSOB3/KgpaKss1fus45btYTuxPk1wrs98WnsJeKHjsqbiM0TSuC4Zl5j7uGjwDdFp 0TZHfz6h4s8P+nS5MfsLUj2IEhhv1nZyU1VKqOaqCwmlhxeZQ3HRBP1SjziZyRLr+D1V z3Ph85o0ddTI6UXcTelOUAAfmHKUqiDsHmntcGoDuMiRuVjeizJh5iabqjWj1QlUlOT/ xWmU296cM6+IuKAX6ZH5R9tK0z2L2Lmx6x3cjjU+zR2BavbT35yMdwd3sZxvwAbmzKba hFtgUgBJU/PqJu+AUsbgscqPkm/rx59v0/+YX5RlpkDdnnlJ6ib6olp4nLwDTson34dU AGGg== MIME-Version: 1.0 X-Received: by 10.42.28.69 with SMTP id m5mr22788218icc.21.1389644106450; Mon, 13 Jan 2014 12:15:06 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.212.8 with HTTP; Mon, 13 Jan 2014 12:15:06 -0800 (PST) In-Reply-To: <008301cf109b$d20238d0$7606aa70$@ndzh.com> References: <008301cf109b$d20238d0$7606aa70$@ndzh.com> Date: Mon, 13 Jan 2014 21:15:06 +0100 X-Google-Sender-Auth: -BJpIXnZzYf20ovvd2_97LreFvU Message-ID: From: Robert Raszuk To: Susan Hares Content-Type: multipart/alternative; boundary=20cf304271c8544d0904efdfbbbc Cc: idr wg , "John G. Scudder" , "Jon Mitchell \(GNS\)" Subject: Re: [Idr] WG LC for X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 20:15:19 -0000 --20cf304271c8544d0904efdfbbbc Content-Type: text/plain; charset=ISO-8859-1 Support: yes r. On Mon, Jan 13, 2014 at 9:12 PM, Susan Hares wrote: > This is to start a 2 week last call on > > Reservation of Last Autonomous System (AS) Numbers > > http://tools.ietf.org/html/draft-ietf-idr-last-as-reservation-01 > > This working group last all we start today and go to 1/27/14. > > We look forward to active discussion. Email should include: > > Support: yes/no > > Thank you, > > Sue and John > > Co-chairs > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --20cf304271c8544d0904efdfbbbc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Support: yes

r.


On Mon,= Jan 13, 2014 at 9:12 PM, Susan Hares <shares@ndzh.com> wrote:=

Th= is is to start a 2 week last call on

Reserv= ation of Last Autonomous System (AS) Numbers

http://tools.ietf.org/html/draft-ietf-idr-la= st-as-reservation-01

This working group last all we start today and go to 1/27/= 14.=A0

We look forward to active = discussion. =A0Email should include:

Support: yes/no

T= hank you,

Sue and John

Co-c= hairs


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


--20cf304271c8544d0904efdfbbbc-- From bdickson@verisign.com Mon Jan 13 12:34:30 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADAC41AE199 for ; Mon, 13 Jan 2014 12:34:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id roh_EONjyHBt for ; Mon, 13 Jan 2014 12:34:28 -0800 (PST) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by ietfa.amsl.com (Postfix) with ESMTP id 5431C1AE01C for ; Mon, 13 Jan 2014 12:34:27 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKUtRNxTzmU6SGfVixDMfx29kZBVVFhe5p@postini.com; Mon, 13 Jan 2014 12:34:17 PST Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s0DKYCKO002834 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Jan 2014 15:34:12 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Mon, 13 Jan 2014 15:34:12 -0500 From: "Dickson, Brian" To: Susan Hares , "'idr wg'" Thread-Topic: [Idr] WG LC for draft-ietf-idr-last-as-reservation-01 Thread-Index: Ac8Qm/8mv2f4+St0QpSZMG2aCSFWXgAAtD8A Date: Mon, 13 Jan 2014 20:34:11 +0000 Message-ID: In-Reply-To: <009601cf109b$ffc83580$ff58a080$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_CEF9B7E3FA46bdicksonverisigncom_" MIME-Version: 1.0 Cc: "Jon.Mitchell@microsoft.com" , "'John G. Scudder'" Subject: Re: [Idr] WG LC for draft-ietf-idr-last-as-reservation-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 20:34:30 -0000 --_000_CEF9B7E3FA46bdicksonverisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Support: yes Brian From: Susan Hares > Date: Monday, January 13, 2014 3:14 PM To: 'idr wg' > Cc: "'John G. Scudder'" >, "Jon.Mitchell@micr= osoft.com" > Subject: [Idr] WG LC for draft-ietf-idr-last-as-reservation-01 [re-sending =96 so web-site indexing works] This is to start a 2 week last call on Reservation of Last Autonomous System (AS) Numbers http://tools.ietf.org/html/draft-ietf-idr-last-as-reservation-01 This working group last all we start today and go to 1/27/14. We look forward to active discussion. Email should include: Support: yes/no Thank you, Sue and John Co-chairs --_000_CEF9B7E3FA46bdicksonverisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <568BC67A56CD6E478AD531C28E5C7441@verisign.com> Content-Transfer-Encoding: quoted-printable
Support: yes

Brian

From: Susan Hares <shares@ndzh.com>
Date: Monday, January 13, 2014 3:14= PM
To: 'idr wg' <idr@ietf.org>
Cc: "'John G. Scudder'" &= lt;jgs@bgp.nu>, "Jon.Mitchell@microsoft.com" <Jon.Mitchell@microsoft.com>= ;
Subject: [Idr] WG LC for draft-ietf= -idr-last-as-reservation-01

[re-sending =96 so web= -site indexing works]

This is to start a 2 week last call on

Reservation of Last Autonomous System (AS) Numbers

http://tools.ietf.org/html/draft-ietf-idr-last-as-reservation-0= 1

This working group last all we start today and go to 1/27/14. 

We look forward to active discussion.  Email should include:

Support: yes/no

Thank you,

Sue and John

Co-chairs

--_000_CEF9B7E3FA46bdicksonverisigncom_-- From farmer@umn.edu Mon Jan 13 13:40:20 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11A211AE1C6 for ; Mon, 13 Jan 2014 13:40:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBMEUjK0f-6L for ; Mon, 13 Jan 2014 13:40:18 -0800 (PST) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.135.88]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA261AE1C1 for ; Mon, 13 Jan 2014 13:40:18 -0800 (PST) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP for ; Mon, 13 Jan 2014 15:40:06 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ie0-f179.google.com [209.85.223.179] #+LO+TS+TR X-Umn-Classification: local Received: by mail-ie0-f179.google.com with SMTP id tp5so2876257ieb.10 for ; Mon, 13 Jan 2014 13:40:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=Iul4na0C6eOrc14GbMDjdvUi2wmAuNzmbiQLFBAvPOc=; b=TPCg/K/mOTGCG3cDoYD2Bem25igjJRsUwqRck/lY6zhoNGCRRrsRGRcohC8jZLpcbM m5uLn1Qjx6+0c3YF7vwPMxAUneV0sYyP7uSjgt30QuIELCh5uxihgwNQFpelZxDJfasz I8ESF73HvagPGk0RYDIQIDDFiJ6W9CaONCy24XPeemYvX/dBbRM4HotoKqjOdpeDbtCH ZfKvLYuXBAIJfoyuiWmforOhnWEZBBltQuPl4DjJk8Mb6RFXbP3ADK0aKMXALAW7LBMV X4IbeTTR8ksaxWS817VfM/9eMota9NGdD24/6nEgi0XbqzXUd0wdS2GxbBw8vWOgyw+v lceA== X-Gm-Message-State: ALoCoQmJOv+PrAyCTHmN1RsutgBQBaas4JE6mMSHWaeKz7K44dARNlVDnlngQlHtskV7p3WSYrCLD637eXt3sjGFuWURWBANJ4aLhAdsyx91P+x18ifs/sSpjA/0AFIapHXxbbumPrRA X-Received: by 10.50.32.66 with SMTP id g2mr21014011igi.44.1389649206307; Mon, 13 Jan 2014 13:40:06 -0800 (PST) X-Received: by 10.50.32.66 with SMTP id g2mr21014003igi.44.1389649206113; Mon, 13 Jan 2014 13:40:06 -0800 (PST) Received: from x-128-101-234-152.uofm-secure.wireless.umn.edu (x-128-101-234-152.uofm-secure.wireless.umn.edu. [128.101.234.152]) by mx.google.com with ESMTPSA id g6sm1138899igg.9.2014.01.13.13.39.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 Jan 2014 13:40:00 -0800 (PST) Message-ID: <52D45D2E.7060703@umn.edu> Date: Mon, 13 Jan 2014 15:39:58 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Susan Hares , 'idr wg' References: <009601cf109b$ffc83580$ff58a080$@ndzh.com> In-Reply-To: <009601cf109b$ffc83580$ff58a080$@ndzh.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Jon.Mitchell@microsoft.com, "'John G. Scudder'" Subject: Re: [Idr] WG LC for draft-ietf-idr-last-as-reservation-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 21:40:20 -0000 I support last call, even without fixing the following nit. After rereading the Draft I have one small nit, Section 4, second paragraph, second sentence, says; Operators that choose to do inbound filtering of Private Use ASNs within the AS_PATH and AS4_PATH attributes SHOULD also filter these Last ASNs. Why limit this statement to inbound filtering? Isn't the statement equally valid for outbound filtering? I think having "inbound" in the sentence is overly specific. I suggest removing "inbound" from the sentence, leaving something like this; Operators that choose to filter Private Use ASNs within the AS_PATH and AS4_PATH attributes SHOULD also filter these Last ASNs. However, if you are trying to emphasize or recommend inbound filtering, please rewrite this so it doesn't also seem to imply that outbound filtering is excluded. Thanks On 1/13/14, 14:14 , Susan Hares wrote: > [re-sending – so web-site indexing works] > > This is to start a 2 week last call on > > Reservation of Last Autonomous System (AS) Numbers > > http://tools.ietf.org/html/draft-ietf-idr-last-as-reservation-01 > > This working group last all we start today and go to 1/27/14. > > We look forward to active discussion. Email should include: > > Support: yes/no > > Thank you, > > Sue and John > > Co-chairs > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From jeff.tantsura@ericsson.com Mon Jan 13 13:42:49 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33CDC1ADFE4 for ; Mon, 13 Jan 2014 13:42:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8U6KVlt1Vwzi for ; Mon, 13 Jan 2014 13:42:47 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 699871ADF43 for ; Mon, 13 Jan 2014 13:42:47 -0800 (PST) X-AuditID: c6180641-b7fbd8e0000011cc-54-52d45dcc5a9d Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 1B.B8.04556.CCD54D25; Mon, 13 Jan 2014 22:42:36 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0347.000; Mon, 13 Jan 2014 16:42:35 -0500 From: Jeff Tantsura To: Susan Hares , 'idr wg' Thread-Topic: [Idr] WG LC for draft-ietf-idr-last-as-reservation-01 Thread-Index: Ac8Qm/8mv2f4+St0QpSZMG2aCSFWXv//5nMA Date: Mon, 13 Jan 2014 21:42:35 +0000 Message-ID: In-Reply-To: <009601cf109b$ffc83580$ff58a080$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_CEF99DB7431CDjefftantsuraericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZXLonVvdM7JUgg1mbNSxe3X7GZLHx/w52 i2e9t9gs/rx5xeLA4rGk+z2Tx5IlP5k8Wnf8ZfeY/fo6awBLFJdNSmpOZllqkb5dAlfGqR6p gsnWFX2/D7I1ML4y6WLk5JAQMJFou/yAHcIWk7hwbz1bFyMXh5DAEUaJIz0n2CGc5YwSu2du ZwapYhMwkPj/7TgLiC0iYCVxfdJRNhCbWSBR4u/ks2BxYQEnic9v77BB1DhLLD17CmgQB5Bt JHHypzZImEVAVWLutNtgJbwC5hJvtj5nArE5gewjp86CrWIEOuj7qTVMEOPFJW49mc8EcaiA xJI955khbFGJl4//sYLYogJ6Em3HzkA9oyzxfc4jFojeGInzneuZIXYJSpyc+YRlAqPoLCRj ZyEpm4WkDCJuIPH+3HxmCFtbYtnC11C2vsTGL2cZIWxriS3tS1iQ1Sxg5FjFyFFanFqWm25k uIkRGJPHJNgcdzAu+GR5iFGag0VJnPfLW+cgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYyl fJsY1mxZdkKZ81VzwyO/Dun53vx7Nv4VZZF867TG4Ef54w6PSCNtQbfKxq2WTFNOpiy+nBD1 zutrqpXIToUF+mHnfrTYVj8yfn/mzt7NExft2P1Z70P3aSsLS1nftIVWMsVP9hTUfLxrf08h YnPQhMh4+2svjXQPnn0gv66igfu81LymicuUWIozEg21mIuKEwHNc1EPlwIAAA== Cc: "Jon.Mitchell@microsoft.com" , "'John G. Scudder'" Subject: Re: [Idr] WG LC for draft-ietf-idr-last-as-reservation-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 21:42:49 -0000 --_000_CEF99DB7431CDjefftantsuraericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Yes/support Cheers, Jeff From: Susan Hares > Date: Monday, January 13, 2014 12:14 PM To: 'idr wg' > Cc: "'John G. Scudder'" >, "Jon.Mitchell@micr= osoft.com" > Subject: [Idr] WG LC for draft-ietf-idr-last-as-reservation-01 [re-sending =96 so web-site indexing works] This is to start a 2 week last call on Reservation of Last Autonomous System (AS) Numbers http://tools.ietf.org/html/draft-ietf-idr-last-as-reservation-01 This working group last all we start today and go to 1/27/14. We look forward to active discussion. Email should include: Support: yes/no Thank you, Sue and John Co-chairs --_000_CEF99DB7431CDjefftantsuraericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <3A7FB9BC54B17B4EB71D4ACA3DBEF184@ericsson.com> Content-Transfer-Encoding: quoted-printable
Yes/support

Cheers,
Jeff

From: Susan Hares <shares@ndzh.com>
Date: Monday, January 13, 2014 12:1= 4 PM
To: 'idr wg' <idr@ietf.org>
Cc: "'John G. Scudder'" &= lt;jgs@bgp.nu>, "Jon.Mitchell@microsoft.com" <Jon.Mitchell@microsoft.com>= ;
Subject: [Idr] WG LC for draft-ietf= -idr-last-as-reservation-01

[re-sending =96 so web= -site indexing works]

This is to start a 2 week last call on

Reservation of Last Autonomous System (AS) Numbers

http://tools.ietf.org/html/draft-ietf-idr-last-as-reservation-0= 1

This working group last all we start today and go to 1/27/14. 

We look forward to active discussion.  Email should include:

Support: yes/no

Thank you,

Sue and John

Co-chairs

--_000_CEF99DB7431CDjefftantsuraericssoncom_-- From jakob.heitz@ericsson.com Mon Jan 13 13:47:36 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238DA1ADF43 for ; Mon, 13 Jan 2014 13:47:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hf0hXOJrtnsX for ; Mon, 13 Jan 2014 13:47:34 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6A81A1DFA for ; Mon, 13 Jan 2014 13:47:34 -0800 (PST) X-AuditID: c6180641-b7fbd8e0000011cc-62-52d45eebc38b Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 29.F8.04556.BEE54D25; Mon, 13 Jan 2014 22:47:23 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0347.000; Mon, 13 Jan 2014 16:47:22 -0500 From: Jakob Heitz To: Susan Hares , 'idr wg' Thread-Topic: [Idr] WG LC for draft-ietf-idr-last-as-reservation-01 Thread-Index: Ac8Qm/8mv2f4+St0QpSZMG2aCSFWXgADKF3w Date: Mon, 13 Jan 2014 21:47:22 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F4700D@eusaamb109.ericsson.se> References: <009601cf109b$ffc83580$ff58a080$@ndzh.com> In-Reply-To: <009601cf109b$ffc83580$ff58a080$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_2F3EBB88EC3A454AAB08915FBF0B8C7E02F4700Deusaamb109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyuXRPlO7ruCtBBtf/qVm8uv2MyWLj/x3s Fs96b7FZ/HnzisWBxWNJ93smjyVLfjJ5tO74y+4x+/V11gCWKC6blNSczLLUIn27BK6Mh1u+ sBX0W1WcaFnJ1sDYbdLFyMkhIWAi8ebTESYIW0ziwr31bF2MXBxCAkcYJVZ++Q/lLGeUuLH2 D1gVm4COxLfrXcwgtoiAlcT1SUfZQGxmgUSJv5PPsnQxcnAICzhJNGzShChxllh69hQ7hG0k cXnvGUaQEhYBVYkjm3NAwrwCvhLn/r0DKxESMJO4MO85mM0pYC5x5NRZsE2MQLd9P7WGCWKT uMStJ/OhbhaQWLLnPDOELSrx8vE/VghbWeL7nEcsEPX5Epuvn2aE2CUocXLmE5YJjKKzkIya haRsFpIyiLiOxILdn9ggbG2JZQtfM8PYZw48ZkIWX8DIvoqRo7Q4tSw33chwEyMw9o5JsDnu YFzwyfIQozQHi5I475e3zkFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGKfHXPbzfKe6Jnfe 00uLpZb+Y1lY/8yKP9Bmv/GGaVEzw9uu+muffZbPaSE8ebXr/d/RraqK2Sw38tgSt1R4xd8x 5Jy2cbnTPpapwUrxYgeeRssrWnKmcZt/XqepY+w8fd2i6PBTd9VP5W25X2QWvyLc6PrBdZba vHsbir6krT16blvD/Jtf65RYijMSDbWYi4oTAYhi/x6LAgAA Cc: "Jon.Mitchell@microsoft.com" , "'John G. Scudder'" Subject: Re: [Idr] WG LC for draft-ietf-idr-last-as-reservation-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 21:47:36 -0000 --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E02F4700Deusaamb109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support: yes. I think intended status should be standards track, not informational, becau= se RFC2119 language is used. Thanks, Jakob. From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, January 13, 2014 12:14 PM To: 'idr wg' Cc: 'John G. Scudder'; Jon.Mitchell@microsoft.com Subject: [Idr] WG LC for draft-ietf-idr-last-as-reservation-01 [re-sending - so web-site indexing works] This is to start a 2 week last call on Reservation of Last Autonomous System (AS) Numbers http://tools.ietf.org/html/draft-ietf-idr-last-as-reservation-01 This working group last all we start today and go to 1/27/14. We look forward to active discussion. Email should include: Support: yes/no Thank you, Sue and John Co-chairs --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E02F4700Deusaamb109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support: yes.

 

I think intended statu= s should be standards track, not informational, because RFC2119 language is= used.

 

Thanks,

Jakob.

 

From: Idr [mai= lto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Monday, January 13, 2014 12:14 PM
To: 'idr wg'
Cc: 'John G. Scudder'; Jon.Mitchell@microsoft.com
Subject: [Idr] WG LC for draft-ietf-idr-last-as-reservation-01<= /o:p>

 

[re-sending – so= web-site indexing works]

This is to start a 2 week last call on

Reservation of Last Autonomous System (AS) Numbers<= /p>

http://tools.ietf.org/html/draft-ietf-idr-last-as-reserv= ation-01

This working group last all we start today and go to 1/27/14. 

We look forward to active discussion.  Email should include:

Support: yes/no

Thank you,

Sue and John

Co-chairs

--_000_2F3EBB88EC3A454AAB08915FBF0B8C7E02F4700Deusaamb109erics_-- From jrmitche@puck.nether.net Mon Jan 13 13:53:47 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAF41AE174 for ; Mon, 13 Jan 2014 13:53:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfNeBku2VNfo for ; Mon, 13 Jan 2014 13:53:45 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 47FA01ADF47 for ; Mon, 13 Jan 2014 13:53:45 -0800 (PST) Received: from puck.nether.net (localhost [127.0.0.1]) by puck.nether.net (8.14.7/8.14.5) with ESMTP id s0DLrW17031319; Mon, 13 Jan 2014 16:53:32 -0500 Received: (from jrmitche@localhost) by puck.nether.net (8.14.7/8.14.7/Submit) id s0DLrWmV031318; Mon, 13 Jan 2014 16:53:32 -0500 Date: Mon, 13 Jan 2014 16:53:32 -0500 From: Jon Mitchell To: David Farmer Message-ID: <20140113215331.GA30854@puck.nether.net> References: <009601cf109b$ffc83580$ff58a080$@ndzh.com> <52D45D2E.7060703@umn.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52D45D2E.7060703@umn.edu> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.7 (puck.nether.net [127.0.0.1]); Mon, 13 Jan 2014 16:53:32 -0500 (EST) Cc: "'John G. Scudder'" , 'idr wg' , Jon.Mitchell@microsoft.com, Susan Hares Subject: Re: [Idr] WG LC for draft-ietf-idr-last-as-reservation-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 21:53:47 -0000 On 13/01/14 15:39 -0600, David Farmer wrote: > I support last call, even without fixing the following nit. > > > After rereading the Draft I have one small nit, Section 4, second > paragraph, second sentence, says; > > Operators that choose to do inbound filtering of Private Use ASNs > within the AS_PATH and AS4_PATH attributes SHOULD also filter these > Last ASNs. > > Why limit this statement to inbound filtering? Isn't the statement > equally valid for outbound filtering? I think having "inbound" in > the sentence is overly specific. I suggest removing "inbound" from > the sentence, leaving something like this; > > Operators that choose to filter Private Use ASNs within the AS_PATH > and AS4_PATH attributes SHOULD also filter these Last ASNs. > > However, if you are trying to emphasize or recommend inbound > filtering, please rewrite this so it doesn't also seem to imply that > outbound filtering is excluded. > David - I thought it would be covered by sentence before that: "These last ASNs MUST NOT be advertised to the global Internet within AS_PATH or AS4_PATH attributes." However, there could be places in their network (not connected to the Internet) where operators do this egress filtering on the AS_PATH and therefore I see no reason to not remove the word you suggest. Cheers, Jon From kotikalapudi.sriram@nist.gov Mon Jan 13 13:54:21 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA3B1AE196 for ; Mon, 13 Jan 2014 13:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-XevDQ3WCKO for ; Mon, 13 Jan 2014 13:54:18 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0210.outbound.protection.outlook.com [207.46.163.210]) by ietfa.amsl.com (Postfix) with ESMTP id 52BB51ADF47 for ; Mon, 13 Jan 2014 13:54:18 -0800 (PST) Received: from BLUPR09MB053.namprd09.prod.outlook.com (10.255.211.146) by BLUPR09MB053.namprd09.prod.outlook.com (10.255.211.146) with Microsoft SMTP Server (TLS) id 15.0.847.13; Mon, 13 Jan 2014 21:54:05 +0000 Received: from BLUPR09MB053.namprd09.prod.outlook.com ([169.254.14.203]) by BLUPR09MB053.namprd09.prod.outlook.com ([169.254.14.203]) with mapi id 15.00.0847.008; Mon, 13 Jan 2014 21:54:05 +0000 From: "Sriram, Kotikalapudi" To: "idr@ietf.org" Thread-Topic: [Idr] WG LC for draft-ietf-idr-last-as-reservation-01 Thread-Index: Ac8QqflAeFX3UjQjTHKOdQefh1c9EQ== Date: Mon, 13 Jan 2014 21:54:05 +0000 Message-ID: <795a8dbd68814d8594588fcb04f477c4@BLUPR09MB053.namprd09.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.140.100] x-forefront-prvs: 00909363D5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(189002)(199002)(31966008)(74502001)(74662001)(47446002)(85306002)(77982001)(69226001)(79102001)(51856001)(63696002)(76176001)(81816001)(76786001)(76796001)(76576001)(76482001)(54356001)(53806001)(46102001)(81686001)(83322001)(74366001)(19580395003)(74316001)(87266001)(59766001)(80976001)(77096001)(83072002)(80022001)(558084003)(85852003)(66066001)(87936001)(65816001)(33646001)(81542001)(49866001)(90146001)(4396001)(54316002)(2656002)(56816005)(47736001)(81342001)(56776001)(92566001)(47976001)(74876001)(50986001)(74706001)(93136001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR09MB053; H:BLUPR09MB053.namprd09.prod.outlook.com; CLIP:129.6.140.100; FPR:; MLV:nspm; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Subject: Re: [Idr] WG LC for draft-ietf-idr-last-as-reservation-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 21:54:21 -0000 Yes, I support. Sriram >[re-sending ? so web-site indexing works] This is to start a 2 week last c= all on >Reservation of Last Autonomous System (AS) Numbers >http://tools.ietf.org/html/draft-ietf-idr-last-as-reservation-01 >This working group last all we start today and go to 1/27/14. From gdawra@cisco.com Mon Jan 13 14:26:05 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E212E1ADF43 for ; Mon, 13 Jan 2014 14:26:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.038 X-Spam-Level: X-Spam-Status: No, score=-15.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49J-evZBBQRK for ; Mon, 13 Jan 2014 14:26:04 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 085081ADA5D for ; Mon, 13 Jan 2014 14:26:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13471; q=dns/txt; s=iport; t=1389651953; x=1390861553; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=nOzdzRS4DqgOOKTZimctwELl43ILpoft56nEdOlNfMc=; b=KDq54jefY9p9cJKGqYJlEL7/GtUceCszJR30M8RYZ2crbf77p+ALtywR bhI6wY3pzXU/Lh3FbcNXaC/zAaGiltlxEb06zSl9KuzELbPwyx4g/rdzD z/lzxzm3ZPSxTV4yyV46nkFZKz7tc1oWtbv9B+5q77t2lTSU/ckIJ2aS7 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsFAMVm1FKtJXG//2dsb2JhbABagkdEOFa5dIEbFnSCJQEBAQQtTBIBCA4DAwEBASg5FAkIAgQBDQWIBMUJF452EQYBhDcEmBeSFYMtgio X-IronPort-AV: E=Sophos;i="4.95,655,1384300800"; d="scan'208,217";a="297074731" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 13 Jan 2014 22:25:52 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0DMPquq026871 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Jan 2014 22:25:52 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.191]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Mon, 13 Jan 2014 16:25:52 -0600 From: "Gaurav Dawra (gdawra)" To: Susan Hares , idr wg Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPEK5qFFswWpaNkEy6W27A1SpVvg== Date: Mon, 13 Jan 2014 22:25:51 +0000 Message-ID: In-Reply-To: <026801cf0d04$af4998a0$0ddcc9e0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.154.213.174] Content-Type: multipart/alternative; boundary="_000_CEF9A7E17BDC1gdawraciscocom_" MIME-Version: 1.0 Cc: "'John G. Scudder'" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 22:26:06 -0000 --_000_CEF9A7E17BDC1gdawraciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. -Gaurav From: Susan Hares > Date: Wednesday, January 8, 2014 10:33 PM To: idr wg > Cc: "'John G. Scudder'" > Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Correcting the header. Sue From: Susan Hares [mailto:shares@ndzh.com] Sent: Thursday, January 09, 2014 1:25 AM To: idr wg (idr@ietf.org) Cc: 'John G. Scudder'; John G. Scudder (jgs@juniper.net) Subject: WG LC for This is a 2 week WG LC for IPR on the following draft: Enhanced Route Refresh Capability for BGP-4 draft-ietf-idr-bgp-enhanced-route-refresh-05.txt The 2 week WG LC starts on 1/9/14 and ends on 1/22/14. The questions are as follows: 1) Do the co-authors or any WG participant know of any IPR on this draft? 2) Do you support the draft-ietf-idr-bgp-enhanced-route-refresh-05.txt For publishing as an RFC? Sample answer: 1) IPR: I do/I do not know of IPR for this draft 2) RFC: Support Comments are always welcome. Sue and John WG chairs --_000_CEF9A7E17BDC1gdawraciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <8481C26CB3876A4FB494DE0DA5A93E82@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Support.

-Gaurav

From: Susan Hares <shares@ndzh.com>
Date: Wednesday, January 8, 2014 10= :33 PM
To: idr wg <idr@ietf.org>
Cc: "'John G. Scudder'" &= lt;jgs@bgp.nu>
Subject: Re: [Idr] WG LC for draft-= ietf-idr-bgp-enhanced-route-refresh

Correcting the header.=

Sue =

 

From: Susan Hares [= mailto:shares@ndzh.com]
Sent: Thursday, January 09, 2014 1:25 AM
To: idr wg (idr@ietf.org)
Cc: 'John G. Scudder'; John G. Scudder (jgs@juniper.net)
Subject: WG LC for

 

This is a 2 week WG LC for IPR on the following draft:

 

Enhanced Route Refresh Capability fo= r BGP-4

draft-ietf-idr-bgp-enhanced-route-refresh-05.txt

 

The 2 week WG LC starts on 1/9/14 and ends on 1/22/14.=

 

The questions are as follows:

 

1)  Do the co-authors or any WG participant know of any I= PR on this draft?

2)  Do you support the draft-ietf-idr-bgp-enhanced-route-= refresh-05.txt

For publishing as an RFC?

 

Sample answer:

1)  IPR: I do/I do not know of IPR for this draft  <= o:p>

2)  RFC: Support

 

 

Comments are always welcome.

 

Sue and John

WG chairs

 

 

 

 --_000_CEF9A7E17BDC1gdawraciscocom_-- From randy@psg.com Mon Jan 13 14:33:23 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26A881ADA5D for ; Mon, 13 Jan 2014 14:33:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7xEBa0PqJWC for ; Mon, 13 Jan 2014 14:33:21 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id AC0281A1F1B for ; Mon, 13 Jan 2014 14:33:21 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1W2q4D-0000kx-FC; Mon, 13 Jan 2014 22:33:09 +0000 Date: Tue, 14 Jan 2014 07:33:07 +0900 Message-ID: From: Randy Bush To: "Susan Hares" In-Reply-To: <009601cf109b$ffc83580$ff58a080$@ndzh.com> References: <009601cf109b$ffc83580$ff58a080$@ndzh.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Tue_Jan_14_07:33:04_2014-1"; micalg=pgp-sha512; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Cc: 'idr wg' , Jon.Mitchell@microsoft.com, "'John G. Scudder'" Subject: Re: [Idr] WG LC for draft-ietf-idr-last-as-reservation-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 22:33:23 -0000 --pgp-sign-Multipart_Tue_Jan_14_07:33:04_2014-1 Content-Type: text/plain; charset=US-ASCII in abstract > IANA has also reserved the ASN of the ^ last --pgp-sign-Multipart_Tue_Jan_14_07:33:04_2014-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAABCgAGBQJS1GmjAAoJEMzMBey4OgLt1mQH/Rpjf7JdOEEcrZQQLKI/4P64 GX+xZPl2FVVODEdrdOYV07Fx2OwBu+fkdQMUJUlrWh1yRcBuXwYLQ6H/tdulwREB MhCfQGpGphmpzscW4geChucBdptfchsNXGf33d879byYljrXEoMXhnCKYoEFkUDG bE/L+7j15tKVUw7/IkqQFCYHCKLh2OlxnymKEj9kOePMgJmmkrsbTcSD5ol8gxFf MeQnPX+zq+hZNZTppNYZwY//sYVOjdxzudBQV1BAQb+rl6ot2jUVw5V0DHFcrOGR synfgi1BQxbk15cGr9ltmAi0tUPA96hz5pzFi/YasmDJFhLHtVuaJf5bDDLDFOU= =Y5+E -----END PGP SIGNATURE----- --pgp-sign-Multipart_Tue_Jan_14_07:33:04_2014-1-- From randy@psg.com Mon Jan 13 14:34:48 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58AD41AE107 for ; Mon, 13 Jan 2014 14:34:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgGWZgNr_oPM for ; Mon, 13 Jan 2014 14:34:46 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id A2C521ADFAE for ; Mon, 13 Jan 2014 14:34:46 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1W2q5W-0000lH-Vn; Mon, 13 Jan 2014 22:34:31 +0000 Date: Tue, 14 Jan 2014 07:34:29 +0900 Message-ID: From: Randy Bush To: Jakob Heitz In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F4700D@eusaamb109.ericsson.se> References: <009601cf109b$ffc83580$ff58a080$@ndzh.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F4700D@eusaamb109.ericsson.se> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Tue_Jan_14_07:34:25_2014-1"; micalg=pgp-sha512; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Cc: "'John G. Scudder'" , 'idr wg' , "Jon.Mitchell@microsoft.com" , Susan Hares Subject: Re: [Idr] WG LC for draft-ietf-idr-last-as-reservation-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 22:34:48 -0000 --pgp-sign-Multipart_Tue_Jan_14_07:34:25_2014-1 Content-Type: text/plain; charset=US-ASCII > I think intended status should be standards track, not informational, > because RFC2119 language is used. not arguing for or against info, but noting that 2119 is often used in info docs. i.e. it is not a reason to choose. randy --pgp-sign-Multipart_Tue_Jan_14_07:34:25_2014-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAABCgAGBQJS1Gn1AAoJEMzMBey4OgLtcQMH/0DnIzXPpJGhzh+zaxT+I9Sf tWYMLn1Z1k5o15RQEfDUWpLkj+4PjEWrPjHIMfBCx7TpgEFn4iUvFY0nFVRIWfrF Jc1GCV05l44+0jv1XkBfbm/p+n1gCYp+sSCuQVmS8FY6308JbEslJHErBMpcOgo9 t0EKTffMro2fAuU0oN/BIXZIeladydjQiTU8LIkx3JjzJ6+usHwpEsonigCOHpZe tkYcgVlmelO6W5k5JTU4Lq+aWFQTkQHItitBrxU77imBu8Im4Rws8ZLmevF1KhVJ xwKJ+SuGZfm1YBJKtcAlkjjzJ13K00GZfOwhKj5AkczYKoP7c2CenoG/MN3jkL8= =GStq -----END PGP SIGNATURE----- --pgp-sign-Multipart_Tue_Jan_14_07:34:25_2014-1-- From jrmitche@puck.nether.net Mon Jan 13 14:36:48 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95ED91ADFAE for ; Mon, 13 Jan 2014 14:36:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c951rCPMf_Kx for ; Mon, 13 Jan 2014 14:36:47 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3B21ADA5D for ; Mon, 13 Jan 2014 14:36:47 -0800 (PST) Received: from puck.nether.net (localhost [127.0.0.1]) by puck.nether.net (8.14.7/8.14.5) with ESMTP id s0DMaZiT010754; Mon, 13 Jan 2014 17:36:35 -0500 Received: (from jrmitche@localhost) by puck.nether.net (8.14.7/8.14.7/Submit) id s0DMaYLr010747; Mon, 13 Jan 2014 17:36:34 -0500 Date: Mon, 13 Jan 2014 17:36:34 -0500 From: Jon Mitchell To: Randy Bush Message-ID: <20140113223634.GA10335@puck.nether.net> References: <009601cf109b$ffc83580$ff58a080$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.7 (puck.nether.net [127.0.0.1]); Mon, 13 Jan 2014 17:36:35 -0500 (EST) Cc: "'John G. Scudder'" , 'idr wg' , Jon.Mitchell@microsoft.com, Susan Hares Subject: Re: [Idr] WG LC for draft-ietf-idr-last-as-reservation-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 22:36:48 -0000 On 14/01/14 07:33 +0900, Randy Bush wrote: > in abstract > > > IANA has also reserved the ASN of the > ^ last Intro I think you mean, thanks, will fix. -Jon From randy@psg.com Mon Jan 13 14:38:58 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6DE31A1F4E for ; Mon, 13 Jan 2014 14:38:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZBCgD2dap0h for ; Mon, 13 Jan 2014 14:38:57 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id C74791A1F1B for ; Mon, 13 Jan 2014 14:38:57 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1W2q9d-0000mU-Ve; Mon, 13 Jan 2014 22:38:46 +0000 Date: Tue, 14 Jan 2014 07:38:44 +0900 Message-ID: From: Randy Bush To: Jon Mitchell In-Reply-To: <20140113223634.GA10335@puck.nether.net> References: <009601cf109b$ffc83580$ff58a080$@ndzh.com> <20140113223634.GA10335@puck.nether.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Tue_Jan_14_07:38:38_2014-1"; micalg=pgp-sha512; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Cc: idr wg Subject: Re: [Idr] WG LC for draft-ietf-idr-last-as-reservation-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 22:38:59 -0000 --pgp-sign-Multipart_Tue_Jan_14_07:38:38_2014-1 Content-Type: text/plain; charset=US-ASCII >> in abstract >>> IANA has also reserved the ASN of the >> ^ last > Intro I think you mean, thanks, will fix. sorry, too much tex for breakfast. randy --pgp-sign-Multipart_Tue_Jan_14_07:38:38_2014-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAABCgAGBQJS1Gr0AAoJEMzMBey4OgLtGLwIAKRpCUtBOQcPQ4OpSwFQcOWU S19EMPr5/c8KRWmkQis+vipOnT/T0YYjj0s8sQaKzOGxtpL9KiZtr68jDsJIFzpd uYsBJAfFIgVWJS/hh/B25mt8TtkBdRuMhoQOCIQz/h2vB6Gg5jki9dhpXo4vQnzr Dkmgqtz2Pl0+IR9YCI/7fYlO+bb4snW6J/BXZ7QOI2gmR6nh19BjJOZbWXbLDmpw 04wG9Sh0ZCJmoVQor0WgkLjCtHahPrPI8n96DZPNh2xpMlTsEnMRKAJ+sRL5+LPo mGFRPrunKb2NeHJNunteOF3ViA/9bIrmx3DMJafKflX64IoJCQZGYQaonDEpaRw= =DQ+F -----END PGP SIGNATURE----- --pgp-sign-Multipart_Tue_Jan_14_07:38:38_2014-1-- From farmer@umn.edu Mon Jan 13 14:42:09 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 834A91AE1BA for ; Mon, 13 Jan 2014 14:42:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbdwIlE8offe for ; Mon, 13 Jan 2014 14:42:08 -0800 (PST) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.135.107]) by ietfa.amsl.com (Postfix) with ESMTP id D684B1A1F4E for ; Mon, 13 Jan 2014 14:42:07 -0800 (PST) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP for ; Mon, 13 Jan 2014 16:41:39 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ie0-f178.google.com [209.85.223.178] #+LO+TS+TR X-Umn-Classification: local Received: by mail-ie0-f178.google.com with SMTP id x13so2194963ief.9 for ; Mon, 13 Jan 2014 14:41:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=LB8MZ8rWwya/KCTQP0jOKbihDNPpkdWooWtHh6bhb2c=; b=XAawrl02kuyviZghS1jLG/yZYhSy4CpqnOmtgZWo82cjq9uHUyzpJ+ukC5OOraHBnb b14fgeZErL5H0DPmZca2N59hvZFZ+oRa+2zty2ASh7qrO2Zf18MOwwjBTOBPSym1bJbA 8WQLOj8CuqrrvZ1NUXO31VXuKnGMvtwfSjiwffDFyd/hE2ykWBrdlfFy32/3zYrFkfnk otMb4x3ctNf154DIR+b/4uHmDn55Fm2+r9axMn7IdGPsGgW+IRJovdRoONcIzQoU9nVr sEdu7SmRKM7X1yatkjJaPqR94oVA4VZCNk8CxjyaMuiKnV42N2O9qqDGU/bD5cc6Z118 G5XA== X-Gm-Message-State: ALoCoQltd3pmtdjly7DdyVOYm6MeNFWWD3IANoJHLhvN1sy1tRCzXzi0Wg/t/QtL58UrHh/mrc5CkIJ9hKAymyRJb6AhK6dapyrmGwGnRP6GO7BWp5CnzpFsoxHQGKYCVkNzB8uHFQFS X-Received: by 10.43.126.66 with SMTP id gv2mr3820730icc.69.1389652898168; Mon, 13 Jan 2014 14:41:38 -0800 (PST) X-Received: by 10.43.126.66 with SMTP id gv2mr3820717icc.69.1389652898001; Mon, 13 Jan 2014 14:41:38 -0800 (PST) Received: from x-128-101-234-152.uofm-secure.wireless.umn.edu (x-128-101-234-152.uofm-secure.wireless.umn.edu. [128.101.234.152]) by mx.google.com with ESMTPSA id a1sm20746749igo.0.2014.01.13.14.41.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 Jan 2014 14:41:37 -0800 (PST) Message-ID: <52D46B9B.9050602@umn.edu> Date: Mon, 13 Jan 2014 16:41:31 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Jon Mitchell References: <009601cf109b$ffc83580$ff58a080$@ndzh.com> <52D45D2E.7060703@umn.edu> <20140113215331.GA30854@puck.nether.net> In-Reply-To: <20140113215331.GA30854@puck.nether.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'John G. Scudder'" , Jon.Mitchell@microsoft.com, 'idr wg' Subject: Re: [Idr] WG LC for draft-ietf-idr-last-as-reservation-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 22:42:09 -0000 On 1/13/14, 15:53 , Jon Mitchell wrote: > On 13/01/14 15:39 -0600, David Farmer wrote: >> I support last call, even without fixing the following nit. >> >> >> After rereading the Draft I have one small nit, Section 4, second >> paragraph, second sentence, says; >> >> Operators that choose to do inbound filtering of Private Use ASNs >> within the AS_PATH and AS4_PATH attributes SHOULD also filter these >> Last ASNs. >> >> Why limit this statement to inbound filtering? Isn't the statement >> equally valid for outbound filtering? I think having "inbound" in >> the sentence is overly specific. I suggest removing "inbound" from >> the sentence, leaving something like this; >> >> Operators that choose to filter Private Use ASNs within the AS_PATH >> and AS4_PATH attributes SHOULD also filter these Last ASNs. >> >> However, if you are trying to emphasize or recommend inbound >> filtering, please rewrite this so it doesn't also seem to imply that >> outbound filtering is excluded. >> > > David - > > I thought it would be covered by sentence before that: > > "These last ASNs MUST NOT be advertised to the global Internet within > AS_PATH or AS4_PATH attributes." > > However, there could be places in their network (not connected to the > Internet) where operators do this egress filtering on the AS_PATH and > therefore I see no reason to not remove the word you suggest. Yes, in a way the first sentence of that paragraph covers it. However, the second sentence does something a little different than the first sentence. The second sentence give you permission to, and makes a recommendation that you, filter these Last ASNs whenever you filter Private Use ASNs. Put another way, for the purpose of filtering the second sentence gives you permission to treat the Last ASNs as if they were Private Use ASNs, but only for the purpose of filtering. And, I don't want anyone to assume that permission is only for inbound filtering, which is kind of what the current second sentence says, with "inbound" in the sentence. See, Matthew Jones' email of 10/23/13 with subject "Re: [Idr] I-D Action: draft-ietf-idr-last-as-reservation-01.txt"; In my opinion he is interpreting things correctly, filter the Last ASNs whenever you filter Private Use ASNs. But, section 5, paragraph 2, probably also applies to Matthew's question as well, as that seems to be a code snippet. Hope that makes my issue a little clearer, and thanks for agreeing to remove "inbound" in that sentence. Thanks. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From iesg-secretary@ietf.org Mon Jan 13 15:06:10 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AACB1AE00A; Mon, 13 Jan 2014 15:06:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yw4bzNebw4ck; Mon, 13 Jan 2014 15:06:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 87AE11AE1DB; Mon, 13 Jan 2014 15:06:06 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140113230606.29515.27801.idtracker@ietfa.amsl.com> Date: Mon, 13 Jan 2014 15:06:06 -0800 Cc: idr mailing list , idr chair , RFC Editor Subject: [Idr] Protocol Action: 'IANA Registries for BGP Extended Communities' to Proposed Standard (draft-ietf-idr-extcomm-iana-02.txt) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 23:06:10 -0000 The IESG has approved the following document: - 'IANA Registries for BGP Extended Communities' (draft-ietf-idr-extcomm-iana-02.txt) as Proposed Standard This document is the product of the Inter-Domain Routing Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-idr-extcomm-iana/ Technical Summary This document reorganizes the IANA Registries for the type values and sub-type values of BGP Extended Communities attribute and the BGP IPv6-Address-Specific Extended Communities attribute. This is done in order to remove inter-dependencies among the registries, thus making it easier for IANA to determine which code points are available for assignment in which registries. This document also clarifies the information that must be provided to IANA when requesting an allocation from one or more of these registries. These changes are compatible with the existing allocations, and thus do not affect protocol implementations. The changes will however impact the "IANA Considerations" sections of future protocol specifications. This document updates RFCs 4360 and 5701. Working Group Summary Approvals were given all round by implementors and deployers. The only problem with a “no-brainer†request is that people forget to comment. Document Quality This is an IANA clean-up. Personnel Susan Hares is the Document Shepherd. Stewart Bryant is the Responsible Area Director. From shares@ndzh.com Mon Jan 13 16:25:04 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBE7D1A8033 for ; Mon, 13 Jan 2014 16:25:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1w8OCeyr_gtx for ; Mon, 13 Jan 2014 16:25:02 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8634C1ACC83 for ; Mon, 13 Jan 2014 16:25:02 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Jakob Heitz'" , "'idr wg'" References: <009601cf109b$ffc83580$ff58a080$@ndzh.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F4700D@eusaamb109.ericsson.se> In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F4700D@eusaamb109.ericsson.se> Date: Mon, 13 Jan 2014 19:24:38 -0500 Message-ID: <00ba01cf10bf$0380bbc0$0a823340$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BB_01CF1095.1AABEC40" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFUHLgnFdayqrX0fhkJ34lvgHCiUAGT+LeVm2yka/A= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: Jon.Mitchell@microsoft.com, "'John G. Scudder'" Subject: Re: [Idr] WG LC for draft-ietf-idr-last-as-reservation-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 00:25:05 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00BB_01CF1095.1AABEC40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Jakob: Thank you for your note regarding standard track. I am checking with Routing AD on this point. For those commenting, please indicate if changing this to a standards track impacts any of our support. Thank you, Sue From: Jakob Heitz [mailto:jakob.heitz@ericsson.com] Sent: Monday, January 13, 2014 4:47 PM To: Susan Hares; 'idr wg' Cc: 'John G. Scudder'; Jon.Mitchell@microsoft.com Subject: RE: [Idr] WG LC for draft-ietf-idr-last-as-reservation-01 Support: yes. I think intended status should be standards track, not informational, because RFC2119 language is used. Thanks, Jakob. From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, January 13, 2014 12:14 PM To: 'idr wg' Cc: 'John G. Scudder'; Jon.Mitchell@microsoft.com Subject: [Idr] WG LC for draft-ietf-idr-last-as-reservation-01 [re-sending - so web-site indexing works] This is to start a 2 week last call on Reservation of Last Autonomous System (AS) Numbers http://tools.ietf.org/html/draft-ietf-idr-last-as-reservation-01 This working group last all we start today and go to 1/27/14. We look forward to active discussion. Email should include: Support: yes/no Thank you, Sue and John Co-chairs ------=_NextPart_000_00BB_01CF1095.1AABEC40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jakob:

 

Thank you for your note = regarding standard track.  I am checking with Routing AD on this = point.

 

For those commenting, = please indicate if changing this to a standards track impacts any of our = support.

 

Thank you, =

 

Sue =

 

From:= = Jakob Heitz [mailto:jakob.heitz@ericsson.com]
Sent: Monday, = January 13, 2014 4:47 PM
To: Susan Hares; 'idr = wg'
Cc: 'John G. Scudder'; = Jon.Mitchell@microsoft.com
Subject: RE: [Idr] WG LC for = draft-ietf-idr-last-as-reservation-01

 

Support: yes.

 

I think intended status = should be standards track, not informational, because RFC2119 language = is used.

 

Thanks,

Jakob.

 

From:= = Idr [mailto:idr-bounces@ietf.org] = On Behalf Of Susan Hares
Sent: Monday, January 13, 2014 = 12:14 PM
To: 'idr wg'
Cc: 'John G. Scudder'; Jon.Mitchell@microsoft.com=
Subject: [Idr] WG LC for = draft-ietf-idr-last-as-reservation-01

 

[re-sending – so web-site indexing works] =

This is to start a 2 week last call on =

Reservation of Last Autonomous System (AS) = Numbers

http://tools.ietf.org/html/draft-ietf-idr-last-as-reservation-01

This working group last all we start today and go to = 1/27/14. 

We look forward to active discussion.  Email = should include:

Support: yes/no

Thank you,

Sue and John

Co-chairs

------=_NextPart_000_00BB_01CF1095.1AABEC40-- From jakob.heitz@ericsson.com Mon Jan 13 17:20:19 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABFA51AE1BE for ; Mon, 13 Jan 2014 17:20:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWQdNT-j9I-w for ; Mon, 13 Jan 2014 17:20:18 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id D6D3E1AE0E0 for ; Mon, 13 Jan 2014 17:20:17 -0800 (PST) X-AuditID: c618062d-b7f278e000005a8f-27-52d490c378ee Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 68.71.23183.3C094D25; Tue, 14 Jan 2014 02:20:04 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0347.000; Mon, 13 Jan 2014 20:20:06 -0500 From: Jakob Heitz To: Randy Bush Thread-Topic: [Idr] WG LC for draft-ietf-idr-last-as-reservation-01 Thread-Index: Ac8Qm/8mv2f4+St0QpSZMG2aCSFWXgADKF3wAAw5z4AABMvMMA== Date: Tue, 14 Jan 2014 01:20:05 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F4727D@eusaamb109.ericsson.se> References: <009601cf109b$ffc83580$ff58a080$@ndzh.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F4700D@eusaamb109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyuXRPrO6RCVeCDGbOY7F4dfsZk8XG/zvY LZ713mKzeNb6ksniz5tXLA6sHku63zN5LFnyk8mjdcdfdo/Zr6+zekydOZsxgDWKyyYlNSez LLVI3y6BK+Nl3wbmgrOsFU/a3jA2MJ5k6WLk5JAQMJH4/+MMK4QtJnHh3nq2LkYuDiGBI4wS p968YodwljNKrNnyghmkik1AR+Lb9S4wW0RATuLiiXeMIEXMArMZJa4tmAE0ioNDWMBJomGT JkSNs8TSs6fYIWwniZU/DzKDlLAIqEosPA92BK+Ar8TbF+9YIHbNYpTYf+M/2EWcAloSDSv/ gxUxAl33/dQaJhCbWUBc4taT+UwQVwtILNlznhnCFpV4+fgf1DfKEt/nPGKBqNeRWLD7ExuE rS2xbOFrZojFghInZz5hmcAoNgvJ2FlIWmYhaZmFpGUBI8sqRo7S4tSy3HQjg02MwBg7JsGm u4Nxz0vLQ4zSHCxK4rxf3joHCQmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamAsZdaa+HTDu68P xPIUmd5uj3i3/+GLpczewlWBzX275Wq+vvpz2v2vVf3DwoWHU3w29j6Je2PYX7t+oVOr5Xlb kcUybAaSNQqhTxKOpHj3SdpNuRn86CFLmft3wdvbb+5eF2HZP9ObW/1NrK3dD407vzUmPLDZ P23COxm9FSb+NsY297el7c1WYinOSDTUYi4qTgQAanuTOX8CAAA= Cc: "'John G. Scudder'" , 'idr wg' , "Jon.Mitchell@microsoft.com" , Susan Hares Subject: Re: [Idr] WG LC for draft-ietf-idr-last-as-reservation-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 01:20:19 -0000 Informational means: Look guys, I am doing this, have a nice day. Standards track means: Listen guys, you need to do this, otherwise we have = interoperability issues. It's standards track. -----Original Message----- From: Randy Bush [mailto:randy@psg.com]=20 Sent: Monday, January 13, 2014 2:34 PM To: Jakob Heitz Cc: Susan Hares; 'idr wg'; Jon.Mitchell@microsoft.com; 'John G. Scudder' Subject: Re: [Idr] WG LC for draft-ietf-idr-last-as-reservation-01 > I think intended status should be standards track, not informational,=20 > because RFC2119 language is used. not arguing for or against info, but noting that 2119 is often used in info= docs. i.e. it is not a reason to choose. randy From randy@psg.com Mon Jan 13 17:27:12 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988F51ACCF2 for ; Mon, 13 Jan 2014 17:27:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHZKM6kqlYnG for ; Mon, 13 Jan 2014 17:27:11 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 170241ACCE2 for ; Mon, 13 Jan 2014 17:27:10 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1W2smN-0001CD-Gv; Tue, 14 Jan 2014 01:26:55 +0000 Date: Tue, 14 Jan 2014 10:26:53 +0900 Message-ID: From: Randy Bush To: Jakob Heitz In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F4727D@eusaamb109.ericsson.se> References: <009601cf109b$ffc83580$ff58a080$@ndzh.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F4700D@eusaamb109.ericsson.se> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F4727D@eusaamb109.ericsson.se> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Tue_Jan_14_10:26:48_2014-1"; micalg=pgp-sha512; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Cc: "'John G. Scudder'" , 'idr wg' , "Jon.Mitchell@microsoft.com" , Susan Hares Subject: Re: [Idr] WG LC for draft-ietf-idr-last-as-reservation-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 01:27:12 -0000 --pgp-sign-Multipart_Tue_Jan_14_10:26:48_2014-1 Content-Type: text/plain; charset=US-ASCII > Informational means: Look guys, I am doing this, have a nice day. > Standards track means: Listen guys, you need to do this, otherwise we > have interoperability issues. i think most folk here are familiar with that space. > It's standards track. as i said > not arguing for or against info, but noting that 2119 is often used in ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > info docs. i.e. it is not a reason to choose. randy --pgp-sign-Multipart_Tue_Jan_14_10:26:48_2014-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAABCgAGBQJS1JJdAAoJEMzMBey4OgLt7JkH/3vXkczojnqVFaiageUkxFMB rQadhE+1OfvoPILOjFuFUPFuwL6LqQvW5ba5wpvdT1tBkO6d+kQhJpc9xFVawtGc Jp9N+hru7+2rIBencxJl9EBVkWchD0m2VQtO5dX/1rF5lzd9HSYjowjHwKhA4/1x 4k0J98oMJ8Pifg0ulOaIMbvkXmBpyhu4s/JEla+fOBo5b6w5bP8YcqMn0rzaApd4 VP0soDLI8OVciz2G0ujP9uZi7quCpV4H3IsJ5Tf43SxI8OANHjvLd3rBu7x49wmI BGj5Qu4DkocQkiFlWCmQZxeqniE/OwbuYcitkSoIZlrUY92gAE6qEI06xsHlHUo= =LZWU -----END PGP SIGNATURE----- --pgp-sign-Multipart_Tue_Jan_14_10:26:48_2014-1-- From shares@ndzh.com Mon Jan 13 17:58:45 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4BA1AE196 for ; Mon, 13 Jan 2014 17:58:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.545 X-Spam-Level: * X-Spam-Status: No, score=1.545 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, J_CHICKENPOX_81=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDWF19i27-1B for ; Mon, 13 Jan 2014 17:58:45 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id CECB21AD8EA for ; Mon, 13 Jan 2014 17:58:44 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Jakob Heitz'" , "'Randy Bush'" References: <009601cf109b$ffc83580$ff58a080$@ndzh.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F4700D@eusaamb109.ericsson.se> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F4727D@eusaamb109.ericsson.se> In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F4727D@eusaamb109.ericsson.se> Date: Mon, 13 Jan 2014 20:58:20 -0500 Message-ID: <012e01cf10cc$1b1186e0$513494a0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFUHLgnFdayqrX0fhkJ34lvgHCiUAGT+LeVAMt3AtgB724Y35tW5UXg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: 'idr wg' , "'John G. Scudder'" , Jon.Mitchell@microsoft.com Subject: Re: [Idr] WG LC for draft-ietf-idr-last-as-reservation-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 01:58:45 -0000 Jakob: Yes, I agree 100% Jakob. Standard assignment of AS numbers can be approached either way. Standards: Look, we are assigning these AS numbers. If you want to play in the Internet - pay attention (standard) because standard implementation will use it. Informational: What 2 bgp peers do in the privacy of their own private ASes, is the business of the two AS administrations. For the DC BGP, this can still work. So... arguments can balance either way. As for me, what's important is keeping the Internet working - so I'm flexible.l Sue -----Original Message----- From: Jakob Heitz [mailto:jakob.heitz@ericsson.com] Sent: Monday, January 13, 2014 8:20 PM To: Randy Bush Cc: Susan Hares; 'idr wg'; Jon.Mitchell@microsoft.com; 'John G. Scudder' Subject: RE: [Idr] WG LC for draft-ietf-idr-last-as-reservation-01 Informational means: Look guys, I am doing this, have a nice day. Standards track means: Listen guys, you need to do this, otherwise we have interoperability issues. It's standards track. -----Original Message----- From: Randy Bush [mailto:randy@psg.com] Sent: Monday, January 13, 2014 2:34 PM To: Jakob Heitz Cc: Susan Hares; 'idr wg'; Jon.Mitchell@microsoft.com; 'John G. Scudder' Subject: Re: [Idr] WG LC for draft-ietf-idr-last-as-reservation-01 > I think intended status should be standards track, not informational, > because RFC2119 language is used. not arguing for or against info, but noting that 2119 is often used in info docs. i.e. it is not a reason to choose. randy From randy@psg.com Mon Jan 13 18:06:40 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7572B1AE1B0 for ; Mon, 13 Jan 2014 18:06:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kviDeNNKG0kh for ; Mon, 13 Jan 2014 18:06:39 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 177531AE1A7 for ; Mon, 13 Jan 2014 18:06:39 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1W2tOa-0001Hf-LC; Tue, 14 Jan 2014 02:06:25 +0000 Date: Tue, 14 Jan 2014 11:06:22 +0900 Message-ID: From: Randy Bush To: Susan Hares In-Reply-To: <012e01cf10cc$1b1186e0$513494a0$@ndzh.com> References: <009601cf109b$ffc83580$ff58a080$@ndzh.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F4700D@eusaamb109.ericsson.se> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F4727D@eusaamb109.ericsson.se> <012e01cf10cc$1b1186e0$513494a0$@ndzh.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Tue_Jan_14_11:06:19_2014-1"; micalg=pgp-sha512; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Cc: idr wg Subject: Re: [Idr] WG LC for draft-ietf-idr-last-as-reservation-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 02:06:40 -0000 --pgp-sign-Multipart_Tue_Jan_14_11:06:19_2014-1 Content-Type: text/plain; charset=US-ASCII actually, since we are waxing pedantic, this is not a protocol spec. hence it belongs in grow. sorry, could not resist. randy --pgp-sign-Multipart_Tue_Jan_14_11:06:19_2014-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAABCgAGBQJS1JueAAoJEMzMBey4OgLtvTIIAIyPlg6BaHzkvAfVkGGcN4Hd XdCGTLUpgzFrAkhdzFcr4ZVQd3nAKS2SS0yOTZXyW8Q6ngvenNyUJbGhcqlHErsn UZ0Hl5c2BGnuiZw5Ibirg2W0fI4JUG459BuXbCMUoLCJ4HDGiuGJzvpYhY/i6mL/ rTlKo/IHDFc7mB7gr8SiDTYoJN2I0el4Tc8dgBeA/f5Ph/snzsmNK+Arq+H806mY Y5AGMKuPoaxmePkxAQly6l0c3bC8Do54osYeF8nev8ou27SqnDyHXGVRWEF6A8YI 6IP/NDd6QPEnHbb+vqPP0n/Mtiu/kVxIAR+HJGC5nUpqKFUb6tlDl60KsGc9nLA= =kCal -----END PGP SIGNATURE----- --pgp-sign-Multipart_Tue_Jan_14_11:06:19_2014-1-- From shares@ndzh.com Mon Jan 13 18:26:05 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD44D1AE1CD for ; Mon, 13 Jan 2014 18:26:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8kW8kJQ71qa for ; Mon, 13 Jan 2014 18:26:04 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 25A151ADFE4 for ; Mon, 13 Jan 2014 18:26:04 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Randy Bush'" References: <009601cf109b$ffc83580$ff58a080$@ndzh.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F4700D@eusaamb109.ericsson.se> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F4727D@eusaamb109.ericsson.se> <012e01cf10cc$1b1186e0$513494a0$@ndzh.com> In-Reply-To: Date: Mon, 13 Jan 2014 21:25:46 -0500 Message-ID: <015101cf10cf$ef4a6aa0$cddf3fe0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFUHLgnFdayqrX0fhkJ34lvgHCiUAGT+LeVAMt3AtgB724Y3wHkkHVcAnxbk1ebM+c64A== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: 'idr wg' Subject: Re: [Idr] WG LC for draft-ietf-idr-last-as-reservation-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 02:26:06 -0000 Randy: Yep... I will cross post WG LC in Grow to see if they have issues, and get review for WG LC. Sue -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Randy Bush Sent: Monday, January 13, 2014 9:06 PM To: Susan Hares Cc: idr wg Subject: Re: [Idr] WG LC for draft-ietf-idr-last-as-reservation-01 actually, since we are waxing pedantic, this is not a protocol spec. hence it belongs in grow. sorry, could not resist. randy From jrmitche@puck.nether.net Tue Jan 14 05:37:23 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6F11AE0D6 for ; Tue, 14 Jan 2014 05:37:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Px21KNp4AKUv for ; Tue, 14 Jan 2014 05:37:22 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 8282A1AE055 for ; Tue, 14 Jan 2014 05:37:22 -0800 (PST) Received: from puck.nether.net (localhost [127.0.0.1]) by puck.nether.net (8.14.7/8.14.5) with ESMTP id s0EDb8vU004941; Tue, 14 Jan 2014 08:37:08 -0500 Received: (from jrmitche@localhost) by puck.nether.net (8.14.7/8.14.7/Submit) id s0EDb72r004938; Tue, 14 Jan 2014 08:37:07 -0500 Date: Tue, 14 Jan 2014 08:37:07 -0500 From: Jon Mitchell To: Susan Hares Message-ID: <20140114133707.GA4554@puck.nether.net> References: <009601cf109b$ffc83580$ff58a080$@ndzh.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F4700D@eusaamb109.ericsson.se> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F4727D@eusaamb109.ericsson.se> <012e01cf10cc$1b1186e0$513494a0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <012e01cf10cc$1b1186e0$513494a0$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.7 (puck.nether.net [127.0.0.1]); Tue, 14 Jan 2014 08:37:08 -0500 (EST) Cc: Jon.Mitchell@microsoft.com, "'John G. Scudder'" , 'idr wg' Subject: Re: [Idr] WG LC for draft-ietf-idr-last-as-reservation-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 13:37:23 -0000 On 13/01/14 20:58 -0500, Susan Hares wrote: > Jakob: > > Yes, I agree 100% Jakob. Standard assignment of AS numbers can be > approached either way. > > Standards: > Look, we are assigning these AS numbers. If you want to play in the Internet > - pay attention (standard) because standard implementation will use it. > > Informational: > What 2 bgp peers do in the privacy of their own private ASes, is the > business of the two AS administrations. For the DC BGP, this can still > work. > > So... arguments can balance either way. To throw another option on the table - BCP (6 specifically), which is where RFC 6996 ended up. This is a primarily a reservation of space draft with a recommendation to operators on (non-)use of that space. -Jon From hannes@juniper.net Tue Jan 14 07:33:18 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A49591ADFB6 for ; Tue, 14 Jan 2014 07:33:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ooxw-h7bsF6k for ; Tue, 14 Jan 2014 07:33:16 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 80F191A1F3F for ; Tue, 14 Jan 2014 07:33:16 -0800 (PST) Received: from mail197-ch1-R.bigfish.com (10.43.68.234) by CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id 14.1.225.22; Tue, 14 Jan 2014 15:33:04 +0000 Received: from mail197-ch1 (localhost [127.0.0.1]) by mail197-ch1-R.bigfish.com (Postfix) with ESMTP id B1E81E01B3; Tue, 14 Jan 2014 15:33:04 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -11 X-BigFish: VPS-11(z3eddszbb2dI98dIzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz1de098h1033IL8275dh1de097h186068hz2fh2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1c0dh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h1155h) Received-SPF: pass (mail197-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=hannes@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail197-ch1 (localhost.localdomain [127.0.0.1]) by mail197-ch1 (MessageSwitch) id 1389713583306557_517; Tue, 14 Jan 2014 15:33:03 +0000 (UTC) Received: from CH1EHSMHS041.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.230]) by mail197-ch1.bigfish.com (Postfix) with ESMTP id 46FBB480062; Tue, 14 Jan 2014 15:33:03 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS041.bigfish.com (10.43.69.250) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 14 Jan 2014 15:33:02 +0000 Received: from juniper.net (193.110.55.19) by pod51010.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.395.1; Tue, 14 Jan 2014 15:33:01 +0000 Date: Tue, 14 Jan 2014 16:32:56 +0100 From: Hannes Gredler To: Susan Hares Message-ID: <20140114153256.GB25540@juniper.net> References: <035201cf0d50$65cbbef0$31633cd0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <035201cf0d50$65cbbef0$31633cd0$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [193.110.55.19] X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: idr wg , draft-dong-idr-te-lsp-distribution@tools.ietf.org Subject: Re: [Idr] WG Adoption call for draft-dong-idr-te-lsp-distribution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 15:33:18 -0000 support - (as an co-author) On Thu, Jan 09, 2014 at 10:35:16AM -0500, Susan Hares wrote: | IDR WG: | | | | This is to give a 2 week Call for adoption of: | | | | Distribution of MPLS Traffic Engineering (TE) LSP State using BGP | | draft-dong-idr-te-lsp-distribution-04 | | | | https://datatracker.ietf.org/doc/draft-dong-idr-te-lsp-distribution/ | | | | WG 2 week calls begins 1/9/14 and ends 1/22/14 | | | | Technical description: | | This document describes a mechanism to collect the Traffic Engineering | (TE) LSP information using BGP. Such information can be used by external | components for path re-optimization, service placement and network | visualization. | | | | | | Sue and John | | IDR co-chairs | | | _______________________________________________ | Idr mailing list | Idr@ietf.org | https://www.ietf.org/mailman/listinfo/idr From jakob.heitz@ericsson.com Tue Jan 14 08:26:41 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE2B1AE129 for ; Tue, 14 Jan 2014 08:26:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0CErkfxISFq for ; Tue, 14 Jan 2014 08:26:39 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 4916B1AE117 for ; Tue, 14 Jan 2014 08:26:39 -0800 (PST) X-AuditID: c6180641-b7fbd8e0000011cc-5a-52d56533ea12 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id E7.C2.04556.33565D25; Tue, 14 Jan 2014 17:26:27 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0347.000; Tue, 14 Jan 2014 11:26:26 -0500 From: Jakob Heitz To: Jon Mitchell Thread-Topic: [Idr] WG LC for draft-ietf-idr-last-as-reservation-01 Thread-Index: Ac8Qm/8mv2f4+St0QpSZMG2aCSFWXgADKF3wAAw5z4AABMvMMAACUsMAABhnnYD//9t8aA== Date: Tue, 14 Jan 2014 16:26:26 +0000 Message-ID: <1F3DAECB-6AE3-4CF1-8BC7-B612B199E208@ericsson.com> References: <009601cf109b$ffc83580$ff58a080$@ndzh.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F4700D@eusaamb109.ericsson.se> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F4727D@eusaamb109.ericsson.se> <012e01cf10cc$1b1186e0$513494a0$@ndzh.com>, <20140114133707.GA4554@puck.nether.net> In-Reply-To: <20140114133707.GA4554@puck.nether.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUyuXRPgq5x6tUgg4cPZC1e3X7GZLHx/w52 i2e9t9gstk7aymrxrPUlk8WfN69YHNg8lnS/Z/JYsuQnk0frjr/sHrNfX2f1mDpzNqNHb9M0 xgC2KC6blNSczLLUIn27BK6MRR8/sRbM56g43X2BrYFxN1sXIyeHhICJxJQt/ewQtpjEhXvr geJcHEICRxglnj/4AeUsZ5R4uuIbI0gVm4COxLfrXcxdjBwcIgLaEnMmgtUwC2xmlPj75B0r SI2wgJPE57d3wDaICDhLLD17ih3CDpO4tG8KO0gvi4CqROdeXhCTV8Be4t41C4hVm5kkeo5+ BivhBDruyaJ8kE5GoNu+n1rDBGIzC4hL3HoynwniZgGJJXvOM0PYohIvH/9jhajRkViw+xMb hK0tsWzha7AaXgFBiZMzn7BMYBSdhWTULCQts5C0zELSsoCRZRUjR2lxalluupHhJkZgbB2T YHPcwbjgk+UhRmkOFiVx3i9vnYOEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MFrb8TMf2Fjz pTvG0tngvmUAb4FFWADLXcNr22uCHvb4rrjA8Icvcdpm75CrG3ayvzAVd97w6XVMxCTHM+KH 5kVUranLXKxyU17tuHt+xdke7iKmbykfn5ff8Hl/3SuEI172SB2LfcXkKvcAfi2rKCGXJh/f 76GMoX/lNm3NqK98V738Q7K9EktxRqKhFnNRcSIA5qlbGXsCAAA= Cc: idr wg , "Jon.Mitchell@microsoft.com" , "John G. Scudder" , Susan Hares Subject: Re: [Idr] WG LC for draft-ietf-idr-last-as-reservation-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 16:26:41 -0000 Sorry I raised this. It's not worth the time. I'll agree to any intended st= atus. -- Jakob Heitz. > On Jan 14, 2014, at 5:37 AM, "Jon Mitchell" wr= ote: >=20 >> On 13/01/14 20:58 -0500, Susan Hares wrote: >> Jakob: >>=20 >> Yes, I agree 100% Jakob. Standard assignment of AS numbers can be >> approached either way. =20 >>=20 >> Standards:=20 >> Look, we are assigning these AS numbers. If you want to play in the Inte= rnet >> - pay attention (standard) because standard implementation will use it. = =20 >>=20 >> Informational:=20 >> What 2 bgp peers do in the privacy of their own private ASes, is the >> business of the two AS administrations. For the DC BGP, this can still >> work.=20 >>=20 >> So... arguments can balance either way. =20 >=20 >=20 > To throw another option on the table - BCP (6 specifically), which is > where RFC 6996 ended up. This is a primarily a reservation of space > draft with a recommendation to operators on (non-)use of that space. >=20 > -Jon >=20 From jeff.tantsura@ericsson.com Tue Jan 14 11:14:06 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A72321AE10D for ; Tue, 14 Jan 2014 11:14:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 573zmx414FhD for ; Tue, 14 Jan 2014 11:14:04 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 56ED31ADF90 for ; Tue, 14 Jan 2014 11:14:04 -0800 (PST) X-AuditID: c618062d-b7f278e000005a8f-af-52d58c6c226d Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 25.4E.23183.D6C85D25; Tue, 14 Jan 2014 20:13:49 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0347.000; Tue, 14 Jan 2014 14:13:51 -0500 From: Jeff Tantsura To: "idr@ietf.org" Thread-Topic: Appreciate your opinion on this WG adoption poll\\FW: [Idr] WG Adoption call for draft-dong-idr-te-lsp-distribution Thread-Index: AQHPEOjhS4S3c51naUS4+XGlt0zwaJqEZWQA Date: Tue, 14 Jan 2014 19:13:51 +0000 Message-ID: In-Reply-To: <76CD132C3ADEF848BD84D028D243C927335BF625@nkgeml512-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_CEFACBC54342Cjefftantsuraericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyuXRPiG5uz9Ugg0/bJSxu7XrKbPHq9jMm ByaPJUt+Mnl8ufyZLYApissmJTUnsyy1SN8ugStj71KHgq82FQ+X3WVtYPxi2sXIySEhYCLx cOIeVghbTOLCvfVsXYxcHEICRxglnl+5zgjhLGeUWLv/KQtIFZuAgcT/b8eBbA4OEQFFiZWf kkHCzAK5EmfuTWAHqRcWaGKU2Nm5lgXEERFoZpQ482krE0iViICRxId9f5lBmlkEVCX+3jIC CfMKmEt8vrkErIRTIEziz9XrYDYj0EXfT61hglggLnHryXwmiEsFJJbsOc8MYYtKvHz8D+wD UQE9ibZjZ9gh4soS3+c8YoHojZG43/uFBWKXoMTJmU9YJjCKzkIydhaSsllIyiDiOhILdn9i g7C1JZYtfM0MY5858Biq11pi5dzXrMhqFjByrGLkKC1OLctNNzLYxAiMtmMSbLo7GPe8tDzE KM3BoiTO++Wtc5CQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxvTlM99NzJx4LOy1LeuMd+kl JQeEq3umT7kt5fB1fpeV2XdW6/n2v4yjd7svb5X1Y+vsD35QMoPh3K+5iudfRDVOM7hnXcmX MeGycq/ObDfFB1LvPPWmrNzMOk1m+Vs3e920nbP8p/3p/Z63Y5ZcUoXu/g0rjpfk7F54U5Sl KFHv1d9b51y/KSmxFGckGmoxFxUnAgDZ6zDZhAIAAA== Cc: "draft-dong-idr-te-lsp-distribution@tools.ietf.org" Subject: Re: [Idr] Appreciate your opinion on this WG adoption poll\\FW: WG Adoption call for draft-dong-idr-te-lsp-distribution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 19:14:06 -0000 --_000_CEFACBC54342Cjefftantsuraericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes/support Cheers, Jeff From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Thursday, January 09, 2014 6:35 PM To: idr wg Cc: draft-dong-idr-te-lsp-distribution@tools.ietf.org Subject: [Idr] WG Adoption call for draft-dong-idr-te-lsp-distribution IDR WG: This is to give a 2 week Call for adoption of: Distribution of MPLS Traffic Engineering (TE) LSP State using BGP draft-dong-idr-te-lsp-distribution-04 https://datatracker.ietf.org/doc/draft-dong-idr-te-lsp-distribution/ WG 2 week calls begins 1/9/14 and ends 1/22/14 Technical description: This document describes a mechanism to collect the Traffic Engineering (TE)= LSP information using BGP. Such information can be used by external compo= nents for path re-optimization, service placement and network visualization= . Sue and John IDR co-chairs --_000_CEFACBC54342Cjefftantsuraericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <562953D78E80D04DAAB3D8D5B1B34942@ericsson.com> Content-Transfer-Encoding: quoted-printable
Yes/support

Cheers,
Jeff

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Thursday, January 09, 2014 6:35 PM
To: idr wg
Cc: draft-dong-idr-te-lsp-distribution@tools.ietf.org
Subject: [Idr] WG Adoption call for draft-dong-idr-te-lsp-distributi= on

 

IDR WG:

 

This is to give a 2 week Call for adoption of:

 

Distribution of MPLS T= raffic Engineering (TE) LSP State using BGP

draft-dong-idr-te-lsp-distribution-04

 

https://datatracker.ietf.org/doc/draft-dong-i= dr-te-lsp-distribution/

 

WG 2 week calls begins 1/9/14 and ends 1/22/14=

 

Technical descripti= on:

This document describe= s a mechanism to collect the Traffic Engineering (TE) LSP information using= BGP.  Such information can be used by external components for path re-optimization, service placement and network visuali= zation.

 

 

Sue and John

IDR co-chairs

 

 --_000_CEFACBC54342Cjefftantsuraericssoncom_-- From shares@ndzh.com Tue Jan 14 12:49:21 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5152F1AE245 for ; Tue, 14 Jan 2014 12:49:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFjOEJapsk2Q for ; Tue, 14 Jan 2014 12:49:20 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id C82371AE170 for ; Tue, 14 Jan 2014 12:49:19 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Jon Mitchell'" References: <009601cf109b$ffc83580$ff58a080$@ndzh.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F4700D@eusaamb109.ericsson.se> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F4727D@eusaamb109.ericsson.se> <012e01cf10cc$1b1186e0$513494a0$@ndzh.com> <20140114133707.GA4554@puck.nether.net> In-Reply-To: <20140114133707.GA4554@puck.nether.net> Date: Tue, 14 Jan 2014 15:48:54 -0500 Message-ID: <009001cf116a$0a021d30$1e065790$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFUHLgnFdayqrX0fhkJ34lvgHCiUAGT+LeVAMt3AtgB724Y3wHkkHVcAQBy8nKbQPt0wA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: 'idr wg' , "'John G. Scudder'" , Jon.Mitchell@microsoft.com Subject: Re: [Idr] WG LC for draft-ietf-idr-last-as-reservation-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 20:49:21 -0000 Jon: Unless we hear otherwise, we'll leave it at informational. I'm still awaiting Stewart Bryant's response as the responsible AD. Sue -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jon Mitchell Sent: Tuesday, January 14, 2014 8:37 AM To: Susan Hares Cc: Jon.Mitchell@microsoft.com; 'John G. Scudder'; 'idr wg' Subject: Re: [Idr] WG LC for draft-ietf-idr-last-as-reservation-01 On 13/01/14 20:58 -0500, Susan Hares wrote: > Jakob: > > Yes, I agree 100% Jakob. Standard assignment of AS numbers can be > approached either way. > > Standards: > Look, we are assigning these AS numbers. If you want to play in the > Internet > - pay attention (standard) because standard implementation will use it. > > Informational: > What 2 bgp peers do in the privacy of their own private ASes, is the > business of the two AS administrations. For the DC BGP, this can > still work. > > So... arguments can balance either way. To throw another option on the table - BCP (6 specifically), which is where RFC 6996 ended up. This is a primarily a reservation of space draft with a recommendation to operators on (non-)use of that space. -Jon _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From mach.chen@huawei.com Tue Jan 14 16:54:51 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C0E1AE119 for ; Tue, 14 Jan 2014 16:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id reDrCL0QkqEy for ; Tue, 14 Jan 2014 16:54:49 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1490E1ADF47 for ; Tue, 14 Jan 2014 16:54:47 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCM50966; Wed, 15 Jan 2014 00:54:35 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 15 Jan 2014 00:53:43 +0000 Received: from SZXEMA406-HUB.china.huawei.com (10.82.72.38) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 15 Jan 2014 00:54:34 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.206]) by SZXEMA406-HUB.china.huawei.com ([10.82.72.38]) with mapi id 14.03.0158.001; Wed, 15 Jan 2014 08:54:31 +0800 From: Mach Chen To: Susan Hares , idr wg Thread-Topic: [Idr] WG Adoption call for draft-dong-idr-te-lsp-distribution Thread-Index: Ac8NUGUcV9wGRG4eS5qk8rMSu5JkuQEO9c1g Date: Wed, 15 Jan 2014 00:54:30 +0000 Message-ID: References: <035201cf0d50$65cbbef0$31633cd0$@ndzh.com> In-Reply-To: <035201cf0d50$65cbbef0$31633cd0$@ndzh.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25D94F848SZXEMA510MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-dong-idr-te-lsp-distribution@tools.ietf.org" Subject: Re: [Idr] WG Adoption call for draft-dong-idr-te-lsp-distribution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 00:54:51 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25D94F848SZXEMA510MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes/Support (as co-author) Best regards, Mach. From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Thursday, January 09, 2014 11:35 PM To: idr wg Cc: draft-dong-idr-te-lsp-distribution@tools.ietf.org Subject: [Idr] WG Adoption call for draft-dong-idr-te-lsp-distribution IDR WG: This is to give a 2 week Call for adoption of: Distribution of MPLS Traffic Engineering (TE) LSP State using BGP draft-dong-idr-te-lsp-distribution-04 https://datatracker.ietf.org/doc/draft-dong-idr-te-lsp-distribution/ WG 2 week calls begins 1/9/14 and ends 1/22/14 Technical description: This document describes a mechanism to collect the Traffic Engineering (TE)= LSP information using BGP. Such information can be used by external compo= nents for path re-optimization, service placement and network visualization= . Sue and John IDR co-chairs --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25D94F848SZXEMA510MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Yes/Support (as co-author)

=  

= Best regards,

= Mach.

=  

From: Idr [mailto:idr-bounces@ietf.org] On B= ehalf Of Susan Hares
Sent: Thursday, January 09, = 2014 11:35 PM
To: idr wg
Cc: draft-dong-idr-te-lsp-di= stribution@tools.ietf.org
Subject: [Idr] WG Adoption c= all for draft-dong-idr-te-lsp-distribution

 

IDR WG= :

&= nbsp;

This i= s to give a 2 week Call for adoption of:

&= nbsp;

Distribution of MPLS Traffic Engineering (TE) LSP = State using BGP

draft-= dong-idr-te-lsp-distribution-04

&= nbsp;

= https://datatracker.ietf.org/doc/draft-dong-idr-te-lsp-distribution/

&= nbsp;

WG 2 w= eek calls begins 1/9/14 and ends 1/22/14

&= nbsp;

Technical description:

This document describes a mechanism to collect the= Traffic Engineering (TE) LSP information using BGP.  Such information can be used by external components for path re-optimization, s= ervice placement and network visualization.

 

 

Sue and John

IDR co-chairs

 

--_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25D94F848SZXEMA510MBXchi_-- From wesley.george@twcable.com Wed Jan 15 07:08:01 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1D311AE38F for ; Wed, 15 Jan 2014 07:08:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.596 X-Spam-Level: * X-Spam-Status: No, score=1.596 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIcpkLkZuFei for ; Wed, 15 Jan 2014 07:08:00 -0800 (PST) Received: from cdcipgw01.twcable.com (cdcipgw01.twcable.com [165.237.91.110]) by ietfa.amsl.com (Postfix) with ESMTP id 552871AE38A for ; Wed, 15 Jan 2014 07:08:00 -0800 (PST) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.95,663,1384318800"; d="scan'208";a="65240463" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdcipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 15 Jan 2014 10:07:22 -0500 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Wed, 15 Jan 2014 10:07:48 -0500 From: "George, Wes" To: Christopher Morrow Date: Wed, 15 Jan 2014 10:07:46 -0500 Thread-Topic: [Idr] Question about draft: draft-ga-idr-as-migration-03.txt Thread-Index: Ac8SA40e7qKZlxliRMOMDETCRyUg8g== Message-ID: References: <-4042749855639388205@gmail297201516> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: idr wg , Robert Raszuk Subject: Re: [Idr] Question about draft: draft-ga-idr-as-migration-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 15:08:01 -0000 VGhvdWdodCBJIHNob3VsZCBtYXliZSB3ZWlnaCBpbiBhcyBhbiBhdXRob3IuLi4NCg0KDQo+Pj4g V2VsbCB0aGlzIGRyYWZ0IGRpc2N1c3NlcyBhcHBsaWNhYmlsaXR5IG9mIGxvY2FsLWFzLCBuby1w cmVwZW5kIGFuZA0KPj4+IHJlcGxhY2UtYXMga25vYnMuIEkNCj4+DQo+PiByaWdodCwgdmVuZG9y IHNwZWNpZmljIGNvbmZpZ3VyYXRpb24gb3B0aW9ucywgbm90IGNoYW5nZXMgdG8gdGhlIGJncA0K Pj4gcHJvdG9jb2wgaXRzZWxmLi4uIEkgdGhvdWdodC4NCj4+DQpUaGUgc3RhdGVkIGdvYWwgaXMg dG8gY29kaWZ5IHRoaXMgYmVoYXZpb3IgYXMgYSBzdGFuZGFyZCBzbyB0aGF0IGl0IGlzDQpjbGVh ciB0aGF0IGZ1dHVyZSBjaGFuZ2VzIHRvIEJHUCBtdXN0IGVpdGhlciBzdXBwb3J0IHRoaXMgZnVu Y3Rpb24gb3INCmV4cGxpY2l0bHkgZ2FpbiBjb25zZW5zdXMgdG8gZGVwcmVjYXRlL2JyZWFrIGl0 Lg0KPj4NCj4+PiBJTU8gaXQgZG9lcyBiZWxvbmcgdG8gSURSIGFzIGltcGxlbWVudGF0aW9ucyBm aXJzdCBuZWVkIHRvIHN1cHBvcnQgc3VjaA0KPj4+IGtub2JzIGluIG9yZGVyIGZvciBvcGVyYXRv cnMgdG8gZGlzY3VzcyBpdHMgdXNlIGluIEdST1cuIEFuZCBmb3IgdGhhdA0KPj4+IGltcGxlbWVu dG9ycyBuZWVkIHRvIHVuZGVyc3RhbmQgdGhlbS4gV2hpbGUgMyBxdW90ZWQgaW1wbGVtZW50YXRp b25zDQo+Pj4gc3VwcG9ydCBpdCAoYmV0dGVyIG9yIHdvcnNlIDopIHRoZXJlIGFyZSBudW1iZXIg b2Ygb3RoZXIgQkdQIGNvZGUgYmFzaXMNCj4+PiB3aGljaCBzdGlsbCBkbyBub3QuDQo+Pg0KPj4g d2FpdCwgc28gbm93IElEUiBpcyBnb2luZyB0byBzcGVjIGltcGxlbWVudGF0aW9uIGtub2JzPyB0 aGF0IHNlZW1zIGxpa2UNCj4+IGl0J3Mgb3V0c2lkZSBvZiB0aGUgY2hhcnRlciB0byBtZS4uLiBv ciByYXRoZXIgSSBkb24ndCBzZWUgdGhpcyBpbiB0aGUNCj4+bGlzdA0KPj4gb2Ygd29yayBpdGVt cyBvciBpbiB0aGUgZ2VuZXJpYyBjaGFydGVyIGZsdWZmIGJlZm9yZSB3b3JrIGl0ZW1zLg0KPj4N Cj4+IGl0IHNlZW1zIG11Y2ggbW9yZSBjbGVhcmx5IHRvIGZpdCBpbiB0aGUgZ3JvdyB3b3JsZCB2 aWV3Li4uIChub3QgdGhhdCBJDQo+PiB3YW50IG1vcmUgd29yayBpbiBncm93LCBidXQgdGhpcyBq dXN0IGRvZXNuJ3Qgc2VlbSBsaWtlIElEUiB0bw0KVGhpcyBpcyBhIGxpdHRsZSBoaW5reSBhcyDi gJxwcm90b2NvbCB3b3Jr4oCdIGJlY2F1c2UgaXTigJlzIGxvY2FsIG9ubHksIHJhdGhlcg0KdGhh biBzb21ldGhpbmcgdGhhdCByZXF1aXJlcyBpbnRlcm9wIGJldHdlZW4gQkdQIHNwZWFrZXJzIGF0 IGFuDQppbXBsZW1lbnRhdGlvbiBsZXZlbCwgYnV0IGFzIG5vdGVkLCBTSURSIHdhcyBhYm91dCB0 byBpbnRyb2R1Y2UgcHJvdG9jb2wNCmNoYW5nZXMgdGhhdCB3b3VsZCBoYXZlIGJyb2tlbiBpdC4g SW4gcHV0dGluZyB0aGlzIGRyYWZ0IGludG8gSURSLCBJ4oCZbQ0KZ29pbmcgYnkgdGhlIHJlY29t bWVuZGF0aW9ucyBmcm9tIHRoZSBmb2xrcyBpbnZvbHZlZCBpbiBTSURSIChvZiB3aGljaCB0aGUN CklEUiBvdmVybGFwIGlzIG5vbnplcm8pIHRoYXQgaW4gb3JkZXIgdG8gZXhwZWN0IFNJRFIgdG8g Y2hhbmdlIHRoZSBCR1BTZWMNCmRlc2lnbiBmb3Igc29tZXRoaW5nIHRoYXQgaXMgaGVhdmlseSB1 c2VkIGJ1dCBub3QgdGVjaG5pY2FsbHkgcGFydCBvZiB0aGUNCkJHUCBTcGVjLCBpdCByZWFsbHkg c2hvdWxkIGJlIHN0YW5kYXJkaXplZCBmaXJzdCwgYW5kIElEUiBpcyB3aGVyZSBCR1ANCnByb3Rv Y29sIHdvcmsgaXMgZG9uZS4gSGVuY2UgdGhlIGRlcGVuZGVudCBub3JtYXRpdmUgcmVmZXJlbmNl IGJldHdlZW4NCmRyYWZ0LWlldGYtc2lkci1hcy1taWdyYXRpb24gYW5kIHRoaXMgZHJhZnQuDQpJ 4oCZbSBvcGVuIHRvIHB1dHRpbmcgaXQgaW4gR1JPVyBpZiB0aGF04oCZcyB3aGVyZSBpdCBtYWtl cyBtb3JlIHNlbnNlLCBqdXN0DQpuZWVkIHNvbWUgc29saWQgZGlyZWN0aW9uIG9uZSB3YXkgb3Ig dGhlIG90aGVyLg0KDQpUaGFua3MNCldlcyBHZW9yZ2UNCg0KDQoNCkFueXRoaW5nIGJlbG93IHRo aXMgbGluZSBoYXMgYmVlbiBhZGRlZCBieSBteSBjb21wYW554oCZcyBtYWlsIHNlcnZlciwgSQ0K aGF2ZSBubyBjb250cm9sIG92ZXIgaXQuDQotLS0tLS0tLS0tLQ0KDQoNClRoaXMgRS1tYWlsIGFu ZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxlIHBy b3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWws IG9yIHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4g VGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlk dWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlm aWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0 aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMg dG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVs LiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdp bmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0K From christopher.morrow@gmail.com Wed Jan 15 07:13:33 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E33BC1AE396 for ; Wed, 15 Jan 2014 07:13:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhMaTShX5niO for ; Wed, 15 Jan 2014 07:13:31 -0800 (PST) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 994B41AE38A for ; Wed, 15 Jan 2014 07:13:30 -0800 (PST) Received: by mail-la0-f49.google.com with SMTP id y1so1477380lam.22 for ; Wed, 15 Jan 2014 07:13:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Z5pd0d9gLEWqiRrTodUjzpiAUeo6QuWVdWUpz/FTD7k=; b=vJHyWR80T3ZP53Ram9rMpsW7XmRfsUrENuGVQxR1guXHrfHBl9UI5ptua1l2dLWST/ 6YpCw0u5EUXkW8XCUDm5luOnDslbs7p+DrgIFEidcHNMs8/Vi2cSCq9RJQcPDrT56n41 Eq6ZGGD41alUHJqN/7l2PIecSWzJPQG7MoiDAiyMcdn8Nz5mwXOZNi/uYmGAbxUDoC+R fwlABfbSvbgM4V/dYTI5XS6NQuHuL2kBiRfRwD2oEH/NO+vllgmV2V8zWyxl0K/uslCi Ru52JNaN8JKTJomjQmOmdB5dawZYx7kf86hmfTd9VU+lq2XFbtvXsx2ZvY8isT/q1ALw 3R0g== MIME-Version: 1.0 X-Received: by 10.152.143.101 with SMTP id sd5mr1897858lab.26.1389798796499; Wed, 15 Jan 2014 07:13:16 -0800 (PST) Received: by 10.152.37.170 with HTTP; Wed, 15 Jan 2014 07:13:16 -0800 (PST) In-Reply-To: References: <-4042749855639388205@gmail297201516> Date: Wed, 15 Jan 2014 10:13:16 -0500 Message-ID: From: Christopher Morrow To: "George, Wes" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: idr wg , Robert Raszuk Subject: Re: [Idr] Question about draft: draft-ga-idr-as-migration-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 15:13:33 -0000 On Wed, Jan 15, 2014 at 10:07 AM, George, Wes w= rote: > Thought I should maybe weigh in as an author... > > >>>> Well this draft discusses applicability of local-as, no-prepend and >>>> replace-as knobs. I >>> >>> right, vendor specific configuration options, not changes to the bgp >>> protocol itself... I thought. >>> > > The stated goal is to codify this behavior as a standard so that it is > clear that future changes to BGP must either support this function or > explicitly gain consensus to deprecate/break it. I don't disagree that documenting the use/practice is a good thing, but: Internet Engineering Task Force W. George Internet-Draft Time Warner Cable Intended status: Informational S. Amante ^^^^^^^^^^^^^ Expires: July 10, 2014 not 'Standard'. >>> >>>> IMO it does belong to IDR as implementations first need to support suc= h >>>> knobs in order for operators to discuss its use in GROW. And for that >>>> implementors need to understand them. While 3 quoted implementations >>>> support it (better or worse :) there are number of other BGP code basi= s >>>> which still do not. >>> >>> wait, so now IDR is going to spec implementation knobs? that seems like >>> it's outside of the charter to me... or rather I don't see this in the >>>list >>> of work items or in the generic charter fluff before work items. >>> >>> it seems much more clearly to fit in the grow world view... (not that I >>> want more work in grow, but this just doesn't seem like IDR to > > This is a little hinky as =93protocol work=94 because it=92s local only, = rather > than something that requires interop between BGP speakers at an > implementation level, but as noted, SIDR was about to introduce protocol > changes that would have broken it. In putting this draft into IDR, I=92m > going by the recommendations from the folks involved in SIDR (of which th= e > IDR overlap is nonzero) that in order to expect SIDR to change the BGPSec > design for something that is heavily used but not technically part of the > BGP Spec, it really should be standardized first, and IDR is where BGP s/standardized/documented/ > protocol work is done. Hence the dependent normative reference between 'protocol' not operational practice... or so I thought, but I'm new and maybe confused, which was why I asked for some guidance from the idr-chairs. > draft-ietf-sidr-as-migration and this draft. > I=92m open to putting it in GROW if that=92s where it makes more sense, j= ust > need some solid direction one way or the other. > yup! and again, I support the draft/documentation. thanks! -chris > Thanks > Wes George > > > > Anything below this line has been added by my company=92s mail server, I > have no control over it. > ----------- > > > This E-mail and any of its attachments may contain Time Warner Cable prop= rietary information, which is privileged, confidential, or subject to copyr= ight belonging to Time Warner Cable. This E-mail is intended solely for the= use of the individual or entity to which it is addressed. If you are not t= he intended recipient of this E-mail, you are hereby notified that any diss= emination, distribution, copying, or action taken in relation to the conten= ts of and attachments to this E-mail is strictly prohibited and may be unla= wful. If you have received this E-mail in error, please notify the sender i= mmediately and permanently delete the original and any copy of this E-mail = and any printout. From xuxiaohu@huawei.com Wed Jan 15 19:09:44 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE631AE120 for ; Wed, 15 Jan 2014 19:09:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtT9rKE1ZjVY for ; Wed, 15 Jan 2014 19:09:42 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2E51ADFD7 for ; Wed, 15 Jan 2014 19:09:42 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCN57760; Thu, 16 Jan 2014 03:09:29 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 16 Jan 2014 03:06:42 +0000 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 16 Jan 2014 03:07:37 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Thu, 16 Jan 2014 11:07:30 +0800 From: Xuxiaohu To: idr wg Thread-Topic: New Version Notification for draft-xu-idr-performance-routing-00.txt Thread-Index: AQHPEmfBKe/BNZV+lEibRRm7KN0GpZqGqv8A Date: Thu, 16 Jan 2014 03:07:29 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082453F7@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [Idr] FWD: New Version Notification for draft-xu-idr-performance-routing-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 03:09:44 -0000 RllJLg0KDQo+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiBpbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+IOWPkemA geaXtumXtDogMjAxNOW5tDHmnIgxNuaXpSAxMTowNQ0KPiDmlLbku7bkuro6IE5paHVpIChuaWh1 aSwgVlJQRGVzaWduKTsgWHV4aWFvaHU7IFlvbmdiaW5nIEZhbjsgTmlodWkgKG5paHVpLA0KPiBW UlBEZXNpZ24pOyBNb2hhbWVkIEJvdWNhZGFpcjsgWHV4aWFvaHU7IENocmlzdGlhbiBKYWNxdWVu ZXQ7IFNvIE5pbmc7IE5pbmcNCj4gU287IENocmlzdGlhbiBKYWNxdWVuZXQ7IE1vaGFtZWQgQm91 Y2FkYWlyOyBGYW4gWW9uZ2JpbmcNCj4g5Li76aKYOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LXh1LWlkci1wZXJmb3JtYW5jZS1yb3V0aW5nLTAwLnR4dA0KPiANCj4gDQo+IEEg bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC14dS1pZHItcGVyZm9ybWFuY2Utcm91dGluZy0wMC50 eHQNCj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBYaWFvaHUgWHUgYW5kIHBv c3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KPiANCj4gTmFtZToJCWRyYWZ0LXh1LWlkci1w ZXJmb3JtYW5jZS1yb3V0aW5nDQo+IFJldmlzaW9uOgkwMA0KPiBUaXRsZToJCVBlcmZvcm1hbmNl LWJhc2VkIEJHUCBSb3V0aW5nIE1lY2hhbmlzbQ0KPiBEb2N1bWVudCBkYXRlOgkyMDE0LTAxLTE2 DQo+IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+IFBhZ2VzOgkJOA0KPiBVUkw6DQo+ IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXh1LWlkci1wZXJmb3Jt YW5jZS1yb3V0aW5nLTAwLnR4dA0KPiBTdGF0dXM6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LXh1LWlkci1wZXJmb3JtYW5jZS1yb3V0aW5nLw0KPiBIdG1saXplZDog ICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteHUtaWRyLXBlcmZvcm1hbmNl LXJvdXRpbmctMDANCj4gDQo+IA0KPiBBYnN0cmFjdDoNCj4gICAgVGhlIGN1cnJlbnQgQkdQIHNw ZWNpZmljYXRpb24gZG9lc24ndCB1c2UgbmV0d29yayBwZXJmb3JtYW5jZQ0KPiAgICBtZXRyaWNz IChlLmcuLCBuZXR3b3JrIGxhdGVuY3kpIGluIHRoZSByb3V0ZSBzZWxlY3Rpb24gZGVjaXNpb24N Cj4gICAgcHJvY2Vzcy4gVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBwZXJmb3JtYW5jZS1iYXNl ZCBCR1Agcm91dGluZw0KPiAgICBtZWNoYW5pc20gaW4gd2hpY2ggbmV0d29yayBsYXRlbmN5IG1l dHJpYyBpcyB0YWtlbiBhcyBvbmUgb2YgdGhlDQo+ICAgIHJvdXRlIHNlbGVjdGlvbiBjcml0ZXJp YS4gVGhpcyByb3V0aW5nIG1lY2hhbmlzbSBpcyB1c2VmdWwgZm9yIHRob3NlDQo+ICAgIHNlcnZl ciBwcm92aWRlcnMgd2l0aCBnbG9iYWwgcmVhY2ggdG8gZGVsaXZlciBsb3ctbGF0ZW5jeSBuZXR3 b3JrDQo+ICAgIGNvbm5lY3Rpdml0eSBzZXJ2aWNlcyB0byB0aGVpciBjdXN0b21lcnMuDQo+IA0K PiANCj4gDQo+IA0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1p bnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQo+IHVudGlsIHRoZSBodG1saXplZCB2 ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+IA0KPiBU aGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From shane@castlepoint.net Wed Jan 15 21:33:48 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5CB11AE4C8 for ; Wed, 15 Jan 2014 21:33:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DriGPt9y4IS for ; Wed, 15 Jan 2014 21:33:46 -0800 (PST) Received: from mail.tcb.net (mail.tcb.net [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF4C1AE4BE for ; Wed, 15 Jan 2014 21:33:46 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.tcb.net (Postfix) with SMTP id B07EF300083 for ; Thu, 16 Jan 2014 05:33:34 +0000 (UTC) Received: from [10.0.1.5] (c-67-188-218-56.hsd1.ca.comcast.net [67.188.218.56]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.tcb.net (Postfix) with ESMTPSA id 8160030007A; Wed, 15 Jan 2014 22:33:33 -0700 (MST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Shane Amante In-Reply-To: Date: Wed, 15 Jan 2014 21:33:32 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3EA58CFA-73CA-419E-87AD-F92AA9F92F93@castlepoint.net> References: <-4042749855639388205@gmail297201516> To: Christopher Morrow X-Mailer: Apple Mail (2.1827) X-DSPAM-Result: Innocent X-DSPAM-Processed: Wed Jan 15 22:33:34 2014 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 52d76f2e42079541713754 X-DSPAM-Factors: 27, new+#+#+confused, 0.40000, to+#+#+#+or, 0.40000, PATH+#+#+#+you, 0.40000, out+#+#+4271, 0.40000, 10+#+#+#+Wes, 0.40000, and+IDR, 0.40000, why+#+#+facto, 0.40000, Please+#+#+that, 0.40000, broken+#+In, 0.40000, is+#+#+#+Error, 0.40000, on+#+#+but, 0.40000, Autonomous+System, 0.40000, Autonomous+System, 0.40000, introduce+#+changes, 0.40000, the+leftmost, 0.40000, Peer+#+The, 0.40000, of+local, 0.40000, the+#+#+standards, 0.40000, dependent+#+reference, 0.40000, we+#+#+several, 0.40000, when+Please, 0.40000, an+#+#+the, 0.40000, autonomous+system, 0.40000, no+#+#+#+a, 0.40000, don't+have, 0.40000, as+#+If, 0.40000, as+#+If, 0.40000 Cc: idr wg , Robert Raszuk Subject: Re: [Idr] Question about draft: draft-ga-idr-as-migration-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 05:33:48 -0000 On Jan 15, 2014, at 7:13 AM, Christopher Morrow = wrote: > On Wed, Jan 15, 2014 at 10:07 AM, George, Wes = wrote: >>>>> IMO it does belong to IDR as implementations first need to support = such >>>>> knobs in order for operators to discuss its use in GROW. And for = that >>>>> implementors need to understand them. While 3 quoted = implementations >>>>> support it (better or worse :) there are number of other BGP code = basis >>>>> which still do not. >>>>=20 >>>> wait, so now IDR is going to spec implementation knobs? that seems = like >>>> it's outside of the charter to me... or rather I don't see this in = the >>>> list >>>> of work items or in the generic charter fluff before work items. >>>>=20 >>>> it seems much more clearly to fit in the grow world view... (not = that I >>>> want more work in grow, but this just doesn't seem like IDR to >>=20 >> This is a little hinky as =93protocol work=94 because it=92s local = only, rather >> than something that requires interop between BGP speakers at an >> implementation level, but as noted, SIDR was about to introduce = protocol >> changes that would have broken it. In putting this draft into IDR, = I=92m >> going by the recommendations from the folks involved in SIDR (of = which the >> IDR overlap is nonzero) that in order to expect SIDR to change the = BGPSec >> design for something that is heavily used but not technically part of = the >> BGP Spec, it really should be standardized first, and IDR is where = BGP >=20 > s/standardized/documented/ >=20 >> protocol work is done. Hence the dependent normative reference = between >=20 > 'protocol' not operational practice... or so I thought, but I'm new > and maybe confused, which was why I asked for some guidance from the > idr-chairs. In my understanding, "protocol" encompasses not only the exact bits on = the wire, but also what stimuli cause those bits to be received from or = sent on the wire and, more importantly, generate errors causing the = "protocol" to malfunction. Example: A (well-formed) TCP SYN causes a = receiver to modify it's state machine and emit a SYN-ACK to the sender. = Surely it does no good to document a TCP header if you don't have a = decent description of what causes TCP flags to be sent and when? =20 Please also consider that the de facto standards documented in this = draft have /also/ been implemented to avoid error conditions in the = protocol, as called out in RFC 4271. -- relates to use of = local-as ---snip--- If the Autonomous System field of the OPEN message is unacceptable, then the Error Subcode MUST be set to Bad Peer AS. The determination of acceptable Autonomous System numbers is outside the scope of this protocol. ---snip--- -- relates to use of = replace-as ---snip--- If the UPDATE message is received from an external peer, the local system MAY check whether the leftmost (with respect to the position of octets in the protocol message) AS in the AS_PATH attribute is equal to the autonomous system number of the peer that sent the message. If the check determines this is not the case, the Error Subcode MUST be set to Malformed AS_PATH. ---snip--- I'll grant you there's enough wiggle room in the above language to drive = a tractor-trailer through easily; however, we all know several = real-world implementations are extremely conservative in what they will = receive (by default), hence why these de facto standards have gone to = great lengths in order to ensure they work reliably in the hostile = conditions of the real-world. In case it's not clear, I also support this being adopted as a WG draft = in IDR. -shane= From shares@ndzh.com Thu Jan 16 03:24:11 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 617231AE30A for ; Thu, 16 Jan 2014 03:24:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FiDVcmJ2dlXH for ; Thu, 16 Jan 2014 03:24:09 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6D51AE2E7 for ; Thu, 16 Jan 2014 03:24:09 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Christopher Morrow'" , "'George, Wes'" References: <-4042749855639388205@gmail297201516> In-Reply-To: Date: Thu, 16 Jan 2014 06:23:43 -0500 Message-ID: <00b801cf12ad$6a5aee20$3f10ca60$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHKcwyD3YKaa8Hbdmi5Lms+hIEcOAH3DiaWAmaMsz0CD9rBNQFO51jsAlyoW96aP6YhoA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: 'idr wg' , "'John G. Scudder'" , 'Robert Raszuk' Subject: Re: [Idr] Question about draft: draft-ga-idr-as-migration-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 11:24:11 -0000 Chris: After hearing George and Shane's comment, we should at least cross-post this draft to grow. It sounds based on George's document like the draft should be fast tracked. If operators really want this documented, then going through list discussion plus adoption, and WG LC call within 8 weeks is a good idea. I think we can both run this through the groups in this time period. The WG LC in IDR depends on their being 2 implementations of the knobs. It really needs to be reviewed by both the implementers and the operations people. I'm fine with accepting it into to IDR and Grow. Perhaps we should investigate adopting in both groups (radical thought!) to get approval the cycles going. In the end, it just becomes and RFC that operators like Shane can point to get the appropriate behavior. If this sounds fine, let's take the mechanism to the 2 ADs. Sue Hares -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Christopher Morrow Sent: Wednesday, January 15, 2014 10:13 AM To: George, Wes Cc: idr wg; Robert Raszuk Subject: Re: [Idr] Question about draft: draft-ga-idr-as-migration-03.txt On Wed, Jan 15, 2014 at 10:07 AM, George, Wes wrote: > Thought I should maybe weigh in as an author... > > >>>> Well this draft discusses applicability of local-as, no-prepend and >>>> replace-as knobs. I >>> >>> right, vendor specific configuration options, not changes to the bgp >>> protocol itself... I thought. >>> > > The stated goal is to codify this behavior as a standard so that it is > clear that future changes to BGP must either support this function or > explicitly gain consensus to deprecate/break it. I don't disagree that documenting the use/practice is a good thing, but: Internet Engineering Task Force W. George Internet-Draft Time Warner Cable Intended status: Informational S. Amante ^^^^^^^^^^^^^ Expires: July 10, 2014 not 'Standard'. >>> >>>> IMO it does belong to IDR as implementations first need to support >>>> such knobs in order for operators to discuss its use in GROW. And >>>> for that implementors need to understand them. While 3 quoted >>>> implementations support it (better or worse :) there are number of >>>> other BGP code basis which still do not. >>> >>> wait, so now IDR is going to spec implementation knobs? that seems >>>like it's outside of the charter to me... or rather I don't see this >>>in the list of work items or in the generic charter fluff before >>>work items. >>> >>> it seems much more clearly to fit in the grow world view... (not >>> that I want more work in grow, but this just doesn't seem like IDR >>> to > > This is a little hinky as "protocol work" because it's local only, > rather than something that requires interop between BGP speakers at an > implementation level, but as noted, SIDR was about to introduce > protocol changes that would have broken it. In putting this draft into > IDR, I'm going by the recommendations from the folks involved in SIDR > (of which the IDR overlap is nonzero) that in order to expect SIDR to > change the BGPSec design for something that is heavily used but not > technically part of the BGP Spec, it really should be standardized > first, and IDR is where BGP s/standardized/documented/ > protocol work is done. Hence the dependent normative reference between 'protocol' not operational practice... or so I thought, but I'm new and maybe confused, which was why I asked for some guidance from the idr-chairs. > draft-ietf-sidr-as-migration and this draft. > I'm open to putting it in GROW if that's where it makes more sense, > just need some solid direction one way or the other. > yup! and again, I support the draft/documentation. thanks! -chris > Thanks > Wes George > > > > Anything below this line has been added by my company's mail server, I > have no control over it. > ----------- > > > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From shares@ndzh.com Thu Jan 16 04:10:18 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6A31AE1F8 for ; Thu, 16 Jan 2014 04:10:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.845 X-Spam-Level: ** X-Spam-Status: No, score=2.845 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97hHlsq7MAsQ for ; Thu, 16 Jan 2014 04:10:17 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 453031AE097 for ; Thu, 16 Jan 2014 04:10:17 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "idr wg" Date: Thu, 16 Jan 2014 07:09:56 -0500 Message-ID: <00e301cf12b3$df905da0$9eb118e0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E4_01CF1289.F6BCEDB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8Ss7+puhBJmcAWS/ebVF4Sg9ldmw== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: draft-ietf-idr-ls-distribution@tools.ietf.org Subject: [Idr] WG LC - for early adoption Code points for draft-ietf-idr-ls-distribution-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 12:10:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00E4_01CF1289.F6BCEDB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all In September 2013 the draft authors have asked for a WG LC on early adoption code point. We had only 1 response for support. The authors have requested another WG LC on allowing this draft to have an early adoption code-point. The authors point out that they are in multiple vendor interoperability trials with 3+ implementations. This begins a 2 week WG LC on giving early code points to: https://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ Please comment on the list. It would aid the chairs if you would include in your comments: a) Support early adoption: yes/no b) Draft is ready for WG LC: yes/no Sue and John Co-chairs ------=_NextPart_000_00E4_01CF1289.F6BCEDB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all

 

In September 2013  the draft = authors have asked for a WG LC on early adoption code point. We had only = 1 response for support.

 

The authors = have requested another WG LC on allowing this draft to have an early = adoption code-point.  The authors point out that they are in = multiple vendor interoperability trials with 3+ implementations. =

 

This begins = a 2 week WG LC on giving early code points to:

 

https://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/

 

 

Please comment on the list. It would = aid the chairs if you would include in your comments: =

 

a)  Support early adoption: = yes/no

b)  Draft is ready for WG LC: yes/no =

 

 

Sue and John =

Co-chairs =  

 

 

------=_NextPart_000_00E4_01CF1289.F6BCEDB0-- From christopher.morrow@gmail.com Thu Jan 16 07:07:25 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3AD1AE390 for ; Thu, 16 Jan 2014 07:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDxL8ByvS55s for ; Thu, 16 Jan 2014 07:07:23 -0800 (PST) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0361AE392 for ; Thu, 16 Jan 2014 07:07:23 -0800 (PST) Received: by mail-lb0-f181.google.com with SMTP id z5so2040410lbh.12 for ; Thu, 16 Jan 2014 07:07:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pJBZ667taMwG2RxKtV8pea3hzwTq9HKT7GufoWUwZqQ=; b=fcQzfkCaBxqMsBF1pv4TaLIK0B6JxxIVOXtnH/cs9eXyiJmrXSy3m7vQOqVXBrDlD8 wbLQ2v7Or1wxnaPEBLn3xBgAleQRdHw2amxkO1w41Q+dB1ellsjQ8XDJLYJrTmtskVoP cvJeVfPVA3x8hq6eqIFlQYDJnXgT1Q3z4bL7iJ5u1pL1EaPiD+jXYOrwZHZq8+F5900T FO8r1GMnnWjk1zGONWF4e+9nkvyrXf0NJIdydPZ4yq4YP9rI/ih6rwsFiQ0C5db3Jg4U yCRME5f8O3VZBw/5xyIwAO7pdCnXhq+zxZXjcexu1xClqeFa2trDtxqXz5ziQ3ME3aSq CW/g== MIME-Version: 1.0 X-Received: by 10.112.159.132 with SMTP id xc4mr602514lbb.62.1389884829882; Thu, 16 Jan 2014 07:07:09 -0800 (PST) Received: by 10.152.37.170 with HTTP; Thu, 16 Jan 2014 07:07:09 -0800 (PST) In-Reply-To: <00b801cf12ad$6a5aee20$3f10ca60$@ndzh.com> References: <-4042749855639388205@gmail297201516> <00b801cf12ad$6a5aee20$3f10ca60$@ndzh.com> Date: Thu, 16 Jan 2014 10:07:09 -0500 Message-ID: From: Christopher Morrow To: Susan Hares Content-Type: text/plain; charset=ISO-8859-1 Cc: "John G. Scudder" , idr wg , Robert Raszuk Subject: Re: [Idr] Question about draft: draft-ga-idr-as-migration-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 15:07:25 -0000 On Thu, Jan 16, 2014 at 6:23 AM, Susan Hares wrote: > Chris: > > After hearing George and Shane's comment, we should at least cross-post > this draft to grow. > It sounds based on George's document like the draft should be fast tracked. > > If operators really want this documented, then going through list > discussion plus adoption, and WG LC call within 8 weeks is a good idea. I > think we can both run this through the groups in this time period. The WG > LC in IDR depends on their being 2 implementations of the knobs. both sets of knobs exist ... one on juniper, one on cisco. (I think wes/shane document these in the draft) > It really needs to be reviewed by both the implementers and the operations > people. I'm fine with accepting it into to IDR and Grow. Perhaps we should > investigate adopting in both groups (radical thought!) to get approval the > cycles going. ha :) so... sure? I suppose in the end as you say having the document published is the goal. > In the end, it just becomes and RFC that operators like Shane can point to > get the appropriate behavior. > > If this sounds fine, let's take the mechanism to the 2 ADs. ok. > Sue Hares > > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Christopher Morrow > Sent: Wednesday, January 15, 2014 10:13 AM > To: George, Wes > Cc: idr wg; Robert Raszuk > Subject: Re: [Idr] Question about draft: draft-ga-idr-as-migration-03.txt > > On Wed, Jan 15, 2014 at 10:07 AM, George, Wes > wrote: >> Thought I should maybe weigh in as an author... >> >> >>>>> Well this draft discusses applicability of local-as, no-prepend and >>>>> replace-as knobs. I >>>> >>>> right, vendor specific configuration options, not changes to the bgp >>>> protocol itself... I thought. >>>> >> >> The stated goal is to codify this behavior as a standard so that it is >> clear that future changes to BGP must either support this function or >> explicitly gain consensus to deprecate/break it. > > I don't disagree that documenting the use/practice is a good thing, but: > Internet Engineering Task Force W. George > Internet-Draft Time Warner Cable > Intended status: Informational S. Amante > ^^^^^^^^^^^^^ > Expires: July 10, 2014 > > not 'Standard'. > >>>> >>>>> IMO it does belong to IDR as implementations first need to support >>>>> such knobs in order for operators to discuss its use in GROW. And >>>>> for that implementors need to understand them. While 3 quoted >>>>> implementations support it (better or worse :) there are number of >>>>> other BGP code basis which still do not. >>>> >>>> wait, so now IDR is going to spec implementation knobs? that seems >>>>like it's outside of the charter to me... or rather I don't see this >>>>in the list of work items or in the generic charter fluff before >>>>work items. >>>> >>>> it seems much more clearly to fit in the grow world view... (not >>>> that I want more work in grow, but this just doesn't seem like IDR >>>> to >> >> This is a little hinky as "protocol work" because it's local only, >> rather than something that requires interop between BGP speakers at an >> implementation level, but as noted, SIDR was about to introduce >> protocol changes that would have broken it. In putting this draft into >> IDR, I'm going by the recommendations from the folks involved in SIDR >> (of which the IDR overlap is nonzero) that in order to expect SIDR to >> change the BGPSec design for something that is heavily used but not >> technically part of the BGP Spec, it really should be standardized >> first, and IDR is where BGP > > s/standardized/documented/ > >> protocol work is done. Hence the dependent normative reference between > > 'protocol' not operational practice... or so I thought, but I'm new and > maybe confused, which was why I asked for some guidance from the idr-chairs. > >> draft-ietf-sidr-as-migration and this draft. >> I'm open to putting it in GROW if that's where it makes more sense, >> just need some solid direction one way or the other. >> > > yup! and again, I support the draft/documentation. > thanks! > -chris > >> Thanks >> Wes George >> >> >> >> Anything below this line has been added by my company's mail server, I >> have no control over it. >> ----------- >> >> >> This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely for > the use of the individual or entity to which it is addressed. If you are not > the intended recipient of this E-mail, you are hereby notified that any > dissemination, distribution, copying, or action taken in relation to the > contents of and attachments to this E-mail is strictly prohibited and may be > unlawful. If you have received this E-mail in error, please notify the > sender immediately and permanently delete the original and any copy of this > E-mail and any printout. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From wwwrun@rfc-editor.org Thu Jan 16 08:05:58 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF331AE35F; Thu, 16 Jan 2014 08:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJOySW6NZ0pQ; Thu, 16 Jan 2014 08:05:57 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id E57631AE13C; Thu, 16 Jan 2014 08:05:56 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id BA9BC7FC39A; Thu, 16 Jan 2014 08:05:44 -0800 (PST) To: ramakrishnadtv@infosys.com, bgp-confederations@st04.pst.org, danny@arbor.net, jgs@juniper.net From: RFC Errata System Message-Id: <20140116160544.BA9BC7FC39A@rfc-editor.org> Date: Thu, 16 Jan 2014 08:05:44 -0800 (PST) Cc: idr@ietf.org, rfc-editor@rfc-editor.org, iesg@ietf.org Subject: [Idr] [Errata Verified] RFC5065 (3791) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 16:05:58 -0000 The following errata report has been verified for RFC5065, "Autonomous System Confederations for BGP". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5065&eid=3791 -------------------------------------- Status: Verified Type: Editorial Reported by: Ramakrishna DTV Date Reported: 2013-11-08 Verified by: Stewart Bryant (IESG) Section: 7 Original Text ------------- Additionally, confederations (as well as route reflectors), by excluding different reachability information from consideration at different locations in a confederation, have been shown [RFC3345] to cause permanent oscillation between candidate routes when using the tie-breaking rules required by BGP [BGP-4]. Corrected Text -------------- Additionally, confederations (as well as route reflectors), by excluding different reachability information from consideration at different locations in a confederation, have been shown [RFC3345] to cause persistent oscillation between candidate routes when using the tie-breaking rules required by BGP [BGP-4]. Notes ----- s/permanent/persistent RFC 3345 nowhere refers to this oscillation as "permanent". It consistently refers to it as "persistent" only. "Permanent" is a much stronger word than "persistent", and I believe is not applicable here. -------------------------------------- RFC5065 (draft-ietf-idr-rfc3065bis-06) -------------------------------------- Title : Autonomous System Confederations for BGP Publication Date : August 2007 Author(s) : P. Traina, D. McPherson, J. Scudder Category : DRAFT STANDARD Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Thu Jan 16 08:13:34 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A33051AE34D; Thu, 16 Jan 2014 08:13:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0YtZ5cv1Y4p; Thu, 16 Jan 2014 08:13:32 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id BFA151AE026; Thu, 16 Jan 2014 08:13:32 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id B37A97FC38D; Thu, 16 Jan 2014 08:13:20 -0800 (PST) To: ramakrishnadtv@infosys.com, danny@tcb.net, vijay@umbc.edu, dwalton@cisco.com, aretana@cisco.com From: RFC Errata System Message-Id: <20140116161320.B37A97FC38D@rfc-editor.org> Date: Thu, 16 Jan 2014 08:13:20 -0800 (PST) Cc: idr@ietf.org, rfc-editor@rfc-editor.org, iesg@ietf.org Subject: [Idr] [Errata Verified] RFC3345 (3787) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 16:13:34 -0000 The following errata report has been verified for RFC3345, "Border Gateway Protocol (BGP) Persistent Route Oscillation Condition". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3345&eid=3787 -------------------------------------- Status: Verified Type: Editorial Reported by: Ramakrishna DTV Date Reported: 2013-11-05 Verified by: Stewart Bryant (IESG) Section: 2.1 Original Text ------------- 1) Ra has the following installed in its BGP table, with the path learned via AS2 marked best: Corrected Text -------------- 1) Ra has the following installed in its BGP table, with the path learned via AS10 marked best: Notes ----- The above text is related to a discussion of topology depicted in Figure 1. This figure does not have AS2 at all. The text should refer to AS10 instead. -------------------------------------- RFC3345 (draft-ietf-idr-route-oscillation-01) -------------------------------------- Title : Border Gateway Protocol (BGP) Persistent Route Oscillation Condition Publication Date : August 2002 Author(s) : D. McPherson, V. Gill, D. Walton, A. Retana Category : INFORMATIONAL Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From shares@ndzh.com Thu Jan 16 08:13:40 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA251AE45E for ; Thu, 16 Jan 2014 08:13:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WoH4N4mPfBkQ for ; Thu, 16 Jan 2014 08:13:38 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 751281AE4BD for ; Thu, 16 Jan 2014 08:13:38 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Christopher Morrow'" References: <-4042749855639388205@gmail297201516> <00b801cf12ad$6a5aee20$3f10ca60$@ndzh.com> In-Reply-To: Date: Thu, 16 Jan 2014 11:13:12 -0500 Message-ID: <003801cf12d5$db178740$914695c0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHKcwyD3YKaa8Hbdmi5Lms+hIEcOAH3DiaWAmaMsz0CD9rBNQFO51jsAlyoW94BJwLQqAH8oyrwmibeWsA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: "'John G. Scudder'" , 'idr wg' , 'Robert Raszuk' Subject: Re: [Idr] Question about draft: draft-ga-idr-as-migration-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 16:13:40 -0000 Chris: Agree - that's my understanding from the document. Therefore: 2 implementation of knobs - means IDR will process adoption plus WG LC. Ok, I will start at WG adoption in IDR call with indication that it will go rapidly to WG LC. In IDR with a draft with two implementations, the chairs normally give people the option to do adoption/WG LC in the same call. I would tend to do this in this case. I propose we both an adoption call/WG LC in both WGs (Grow /IDR). We can then write up shepherd reports and let the ADs sort it out at the IESG. Sue -----Original Message----- From: Christopher Morrow [mailto:christopher.morrow@gmail.com] Sent: Thursday, January 16, 2014 10:07 AM To: Susan Hares Cc: George, Wes; idr wg; Robert Raszuk; John G. Scudder; John G. Scudder Subject: Re: [Idr] Question about draft: draft-ga-idr-as-migration-03.txt On Thu, Jan 16, 2014 at 6:23 AM, Susan Hares wrote: > Chris: > > After hearing George and Shane's comment, we should at least > cross-post this draft to grow. > It sounds based on George's document like the draft should be fast tracked. > > If operators really want this documented, then going through list > discussion plus adoption, and WG LC call within 8 weeks is a good idea. I > think we can both run this through the groups in this time period. The WG > LC in IDR depends on their being 2 implementations of the knobs. both sets of knobs exist ... one on juniper, one on cisco. (I think wes/shane document these in the draft) > It really needs to be reviewed by both the implementers and the > operations people. I'm fine with accepting it into to IDR and Grow. > Perhaps we should investigate adopting in both groups (radical > thought!) to get approval the cycles going. ha :) so... sure? I suppose in the end as you say having the document published is the goal. > In the end, it just becomes and RFC that operators like Shane can > point to get the appropriate behavior. > > If this sounds fine, let's take the mechanism to the 2 ADs. ok. > Sue Hares > > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Christopher > Morrow > Sent: Wednesday, January 15, 2014 10:13 AM > To: George, Wes > Cc: idr wg; Robert Raszuk > Subject: Re: [Idr] Question about draft: > draft-ga-idr-as-migration-03.txt > > On Wed, Jan 15, 2014 at 10:07 AM, George, Wes > > wrote: >> Thought I should maybe weigh in as an author... >> >> >>>>> Well this draft discusses applicability of local-as, no-prepend >>>>> and replace-as knobs. I >>>> >>>> right, vendor specific configuration options, not changes to the >>>> bgp protocol itself... I thought. >>>> >> >> The stated goal is to codify this behavior as a standard so that it >> is clear that future changes to BGP must either support this function >> or explicitly gain consensus to deprecate/break it. > > I don't disagree that documenting the use/practice is a good thing, but: > Internet Engineering Task Force W. George > Internet-Draft Time Warner Cable > Intended status: Informational S. Amante > ^^^^^^^^^^^^^ > Expires: July 10, 2014 > > not 'Standard'. > >>>> >>>>> IMO it does belong to IDR as implementations first need to support >>>>> such knobs in order for operators to discuss its use in GROW. And >>>>> for that implementors need to understand them. While 3 quoted >>>>> implementations support it (better or worse :) there are number of >>>>> other BGP code basis which still do not. >>>> >>>> wait, so now IDR is going to spec implementation knobs? that seems >>>>like it's outside of the charter to me... or rather I don't see >>>>this in the list of work items or in the generic charter fluff >>>>before work items. >>>> >>>> it seems much more clearly to fit in the grow world view... (not >>>> that I want more work in grow, but this just doesn't seem like IDR >>>> to >> >> This is a little hinky as "protocol work" because it's local only, >> rather than something that requires interop between BGP speakers at >> an implementation level, but as noted, SIDR was about to introduce >> protocol changes that would have broken it. In putting this draft >> into IDR, I'm going by the recommendations from the folks involved in >> SIDR (of which the IDR overlap is nonzero) that in order to expect >> SIDR to change the BGPSec design for something that is heavily used >> but not technically part of the BGP Spec, it really should be >> standardized first, and IDR is where BGP > > s/standardized/documented/ > >> protocol work is done. Hence the dependent normative reference >> between > > 'protocol' not operational practice... or so I thought, but I'm new > and maybe confused, which was why I asked for some guidance from the idr-chairs. > >> draft-ietf-sidr-as-migration and this draft. >> I'm open to putting it in GROW if that's where it makes more sense, >> just need some solid direction one way or the other. >> > > yup! and again, I support the draft/documentation. > thanks! > -chris > >> Thanks >> Wes George >> >> >> >> Anything below this line has been added by my company's mail server, >> I have no control over it. >> ----------- >> >> >> This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject > to copyright belonging to Time Warner Cable. This E-mail is intended > solely for the use of the individual or entity to which it is > addressed. If you are not the intended recipient of this E-mail, you > are hereby notified that any dissemination, distribution, copying, or > action taken in relation to the contents of and attachments to this > E-mail is strictly prohibited and may be unlawful. If you have > received this E-mail in error, please notify the sender immediately > and permanently delete the original and any copy of this E-mail and any printout. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From bruno.decraene@orange.com Thu Jan 16 08:21:39 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2721C1AE3C8 for ; Thu, 16 Jan 2014 08:21:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDS1RRmFU5WC for ; Thu, 16 Jan 2014 08:21:36 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDFA1AE37E for ; Thu, 16 Jan 2014 08:21:36 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 0ABB62AC6A9; Thu, 16 Jan 2014 17:21:23 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id D4B5015805E; Thu, 16 Jan 2014 17:21:22 +0100 (CET) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Thu, 16 Jan 2014 17:21:22 +0100 From: To: Susan Hares Thread-Topic: [Idr] WG LC - for early adoption Code points for draft-ietf-idr-ls-distribution-04 Thread-Index: Ac8Ss7+puhBJmcAWS/ebVF4Sg9ldmwAIg8lQ Date: Thu, 16 Jan 2014 16:21:22 +0000 Message-ID: <12880_1389889282_52D80702_12880_10931_1_53C29892C857584299CBF5D05346208A070DA8B2@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <00e301cf12b3$df905da0$9eb118e0$@ndzh.com> In-Reply-To: <00e301cf12b3$df905da0$9eb118e0$@ndzh.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A070DA8B2PEXCVZYM11corpo_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.16.5114 Cc: "draft-ietf-idr-ls-distribution@tools.ietf.org" , idr wg Subject: Re: [Idr] WG LC - for early adoption Code points for draft-ietf-idr-ls-distribution-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 16:21:39 -0000 --_000_53C29892C857584299CBF5D05346208A070DA8B2PEXCVZYM11corpo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Susan, John, a) Support early adoption: yes I clearly support early adoption code-point. For clarification on the mailing list, could you please state the code-poin= t being requested? I guess that this is from the BGP Path Attributes registry since the draft = state that they already got early allocation for AFI & SAFI. Thanks, Regards, Bruno From: Susan Hares Sent: Thursday, January 16, 2014 1:10 PM Hi all In September 2013 the draft authors have asked for a WG LC on early adopti= on code point. We had only 1 response for support. The authors have requested another WG LC on allowing this draft to have an = early adoption code-point. The authors point out that they are in multiple= vendor interoperability trials with 3+ implementations. This begins a 2 week WG LC on giving early code points to: https://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ Please comment on the list. It would aid the chairs if you would include in= your comments: b) Support early adoption: yes/no c) Draft is ready for WG LC: yes/no Sue and John Co-chairs ___________________________________________________________________________= ______________________________________________ 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, 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 authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A070DA8B2PEXCVZYM11corpo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Susan, John,

 

a)  Support early adoption: yes

 

I clear= ly support early adoption code-point.

&n= bsp;

For cla= rification on the mailing list, could you please state the code-point being= requested?

I guess= that this is from the BGP Path Attributes registry since the draft state t= hat they already got early allocation for AFI & SAFI.=

&n= bsp;

Thanks,=

Regards= ,

Bruno

&n= bsp;

From: Susan Hares Sent: Thursday, January 16, 2014 1:10 PM

 

Hi all

 

In September 2013  the draft authors have asked for a W= G LC on early adoption code point. We had only 1 response for support.

 

The authors have requested another WG LC on allowing this dr= aft to have an early adoption code-point.  The authors point out that = they are in multiple vendor interoperability trials with 3+ implementations.

 

This begins a 2 week WG LC on giving early code points to:

 

https://datatracker.ietf.org/doc/draft-ietf-idr-ls-distrib= ution/

 

 

Please comment on the list. It would aid the chairs if you w= ould include in your comments:

 

b)  Support early adoption: yes/no

c)  Draft is ready for WG LC: yes/no

 

 

Sue and John

Co-chairs  

 

 

______________________________________________________________________=
___________________________________________________

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,
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 authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A070DA8B2PEXCVZYM11corpo_-- From hannes@juniper.net Fri Jan 17 00:12:41 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8462D1A1F06 for ; Fri, 17 Jan 2014 00:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ArePStZOozd3 for ; Fri, 17 Jan 2014 00:12:38 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id 80C071A1F05 for ; Fri, 17 Jan 2014 00:12:38 -0800 (PST) Received: from mail49-co1-R.bigfish.com (10.243.78.238) by CO1EHSOBE026.bigfish.com (10.243.66.89) with Microsoft SMTP Server id 14.1.225.22; Fri, 17 Jan 2014 08:12:25 +0000 Received: from mail49-co1 (localhost [127.0.0.1]) by mail49-co1-R.bigfish.com (Postfix) with ESMTP id 785408C0072; Fri, 17 Jan 2014 08:12:25 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0511HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(z579eh579fhz98dI9371I1432I14ffIzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz1de098h1033IL8275bh8275dh1de097h186068hz2fh2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e23h1fe8h1ff5h2052h20b3h2218h2216h226dh22d0h2327h2336h2438h2461h2487h1155h) Received-SPF: pass (mail49-co1: domain of juniper.net designates 157.56.245.197 as permitted sender) client-ip=157.56.245.197; envelope-from=hannes@juniper.net; helo=CH1PRD0511HT005.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail49-co1 (localhost.localdomain [127.0.0.1]) by mail49-co1 (MessageSwitch) id 138994634443001_19703; Fri, 17 Jan 2014 08:12:24 +0000 (UTC) Received: from CO1EHSMHS032.bigfish.com (unknown [10.243.78.234]) by mail49-co1.bigfish.com (Postfix) with ESMTP id F08199C0064; Fri, 17 Jan 2014 08:12:23 +0000 (UTC) Received: from CH1PRD0511HT005.namprd05.prod.outlook.com (157.56.245.197) by CO1EHSMHS032.bigfish.com (10.243.66.42) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 17 Jan 2014 08:12:23 +0000 Received: from [172.29.65.179] (193.110.55.15) by pod51010.outlook.com (10.255.159.40) with Microsoft SMTP Server (TLS) id 14.16.395.1; Fri, 17 Jan 2014 08:12:22 +0000 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="us-ascii" From: Hannes Gredler In-Reply-To: <12880_1389889282_52D80702_12880_10931_1_53C29892C857584299CBF5D05346208A070DA8B2@PEXCVZYM11.corporate.adroot.infra.ftgroup> Date: Fri, 17 Jan 2014 09:12:17 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <00e301cf12b3$df905da0$9eb118e0$@ndzh.com> <12880_1389889282_52D80702_12880_10931_1_53C29892C857584299CBF5D05346208A070DA8B2@PEXCVZYM11.corporate.adroot.infra.ftgroup> To: X-Mailer: Apple Mail (2.1283) X-Originating-IP: [193.110.55.15] X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "draft-ietf-idr-ls-distribution@tools.ietf.org" , Susan Hares , idr wg Subject: Re: [Idr] WG LC - for early adoption Code points for draft-ietf-idr-ls-distribution-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 08:12:41 -0000 hi bruno, your understanding is correct; - we need a "official" code-point for the = link-state attribute. (as we do not want to ship with code-point 99 that we have used for = interop testing ;-)). /hannes On Jan 16, 2014, at 5:21 PM, wrote: > Hi Susan, John, > =20 > a) Support early adoption: yes > =20 > I clearly support early adoption code-point. > =20 > For clarification on the mailing list, could you please state the = code-point being requested? > I guess that this is from the BGP Path Attributes registry since the = draft state that they already got early allocation for AFI & SAFI. > From: Susan Hares Sent: Thursday, January 16, 2014 1:10 PM >=20 > =20 > Hi all > =20 > In September 2013 the draft authors have asked for a WG LC on early = adoption code point. We had only 1 response for support. > =20 > The authors have requested another WG LC on allowing this draft to = have an early adoption code-point. The authors point out that they are = in multiple vendor interoperability trials with 3+ implementations. > =20 > This begins a 2 week WG LC on giving early code points to: > =20 > https://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ > =20 > =20 > Please comment on the list. It would aid the chairs if you would = include in your comments: > =20 > b) Support early adoption: yes/no > c) Draft is ready for WG LC: yes/no > =20 > =20 > Sue and John > Co-chairs =20 > =20 > =20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From robert.varga@pantheon.sk Fri Jan 17 06:08:17 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 212811AE0EA for ; Fri, 17 Jan 2014 06:08:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.568 X-Spam-Level: X-Spam-Status: No, score=0.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, RP_MATCHES_RCVD=-0.538] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id weLjtkpBo7mP for ; Fri, 17 Jan 2014 06:08:15 -0800 (PST) Received: from amalka.pantheon.sk (amalka.pantheon.sk [81.89.59.174]) by ietfa.amsl.com (Postfix) with ESMTP id C2CF91AE0E0 for ; Fri, 17 Jan 2014 06:08:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by amalka.pantheon.sk (Postfix) with ESMTP id F0C8C1FFC5 for ; Fri, 17 Jan 2014 15:08:00 +0100 (CET) X-Virus-Scanned: amavisd-new at pantheon.sk Authentication-Results: amalka.pantheon.sk (amavisd-new); dkim=pass (1024-bit key) header.d=pantheon.sk Received: from amalka.pantheon.sk ([127.0.0.1]) by localhost (amalka.pantheon.sk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsmEWHbUKGKQ for ; Fri, 17 Jan 2014 15:07:56 +0100 (CET) Received: from cipisek.dmz.pantheon.local (cipisek.pantheon.sk [81.89.59.176]) by amalka.pantheon.sk (Postfix) with ESMTP for ; Fri, 17 Jan 2014 15:07:56 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by cipisek.dmz.pantheon.local (Postfix) with ESMTP id F28F014CA09 for ; Fri, 17 Jan 2014 15:07:55 +0100 (CET) Received: from cipisek.dmz.pantheon.local ([127.0.0.1]) by localhost (cipisek.dmz.pantheon.local [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id QfhWgZP4009p for ; Fri, 17 Jan 2014 15:07:55 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by cipisek.dmz.pantheon.local (Postfix) with ESMTP id 5241715B8BE for ; Fri, 17 Jan 2014 15:07:55 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.7.1 cipisek.dmz.pantheon.local 5241715B8BE DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pantheon.sk; s=D7204E10-2735-11E2-9595-0BDFE9028503; t=1389967675; bh=UjjT0+6B42v7AG/6Gmu+wt5DJj834aq7iMrYb2Ht7Ak=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type; b=yoJPw6bF1QGbL6xfiaxY2S+iDblvhZH+fmDFJH8ikJ3y/HpJLnlmupIhZX9Dfhp6B YiS4Wrwe/C1WhU7yNDkKGTnp/xn/O/VwwFDNdkuQ8lNItHlhbR8Aoh6UwTmBfe/l+9 6oCxXsAibjPqaqA+Y2Lq9bUHMepZPbjymJlmdJzo= X-Virus-Scanned: amavisd-new at pantheon.sk Received: from cipisek.dmz.pantheon.local ([127.0.0.1]) by localhost (cipisek.dmz.pantheon.local [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 8dDmmqTAmls7 for ; Fri, 17 Jan 2014 15:07:55 +0100 (CET) Received: from [172.16.4.97] (unknown [172.16.4.97]) by cipisek.dmz.pantheon.local (Postfix) with ESMTPSA id 2BDC114CA09 for ; Fri, 17 Jan 2014 15:07:55 +0100 (CET) Message-ID: <52D93936.7030603@pantheon.sk> Date: Fri, 17 Jan 2014 15:07:50 +0100 From: Robert Varga User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: idr@ietf.org References: <00e301cf12b3$df905da0$9eb118e0$@ndzh.com> In-Reply-To: <00e301cf12b3$df905da0$9eb118e0$@ndzh.com> Content-Type: multipart/alternative; boundary="------------060106090608000309060809" Subject: Re: [Idr] WG LC - for early adoption Code points for draft-ietf-idr-ls-distribution-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 14:08:17 -0000 This is a multi-part message in MIME format. --------------060106090608000309060809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 01/16/2014 01:09 PM, Susan Hares wrote: > > Hi all > > In September 2013 the draft authors have asked for a WG LC on early > adoption code point. We had only 1 response for support. > > The authors have requested another WG LC on allowing this draft to > have an early adoption code-point. The authors point out that they are > in multiple vendor interoperability trials with 3+ implementations. > > This begins a 2 week WG LC on giving early code points to: > > https://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ > > Please comment on the list. It would aid the chairs if you would > include in your comments: > > a)Support early adoption: yes/no > Yes. > b)Draft is ready for WG LC: yes/no > Yes. Regards, Robert --------------060106090608000309060809 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 01/16/2014 01:09 PM, Susan Hares wrote:

Hi all

 

In September 2013  the draft authors have asked for a WG LC on early adoption code point. We had only 1 response for support.

 

The authors have requested another WG LC on allowing this draft to have an early adoption code-point.  The authors point out that they are in multiple vendor interoperability trials with 3+ implementations.

 

This begins a 2 week WG LC on giving early code points to:

 

https://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/

 

 

Please comment on the list. It would aid the chairs if you would include in your comments:

 

a)  Support early adoption: yes/no


Yes.

b)  Draft is ready for WG LC: yes/no


Yes.

Regards,
Robert

--------------060106090608000309060809-- From jhaas@slice.pfrc.org Fri Jan 17 07:56:59 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54AD71AE12D for ; Fri, 17 Jan 2014 07:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwOPwK8_UaaY for ; Fri, 17 Jan 2014 07:56:58 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 11FC51AE10B for ; Fri, 17 Jan 2014 07:56:58 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 97570C2FE; Fri, 17 Jan 2014 10:56:45 -0500 (EST) Date: Fri, 17 Jan 2014 10:56:45 -0500 From: Jeffrey Haas To: Susan Hares Message-ID: <20140117155645.GB20758@pfrc> References: <00e301cf12b3$df905da0$9eb118e0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00e301cf12b3$df905da0$9eb118e0$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: idr wg , draft-ietf-idr-ls-distribution@tools.ietf.org Subject: Re: [Idr] WG LC - for early adoption Code points for draft-ietf-idr-ls-distribution-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 15:56:59 -0000 On Thu, Jan 16, 2014 at 07:09:56AM -0500, Susan Hares wrote: > This begins a 2 week WG LC on giving early code points to: > > https://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ > > Please comment on the list. It would aid the chairs if you would include in > your comments: > > a) Support early adoption: yes/no Yes (absolutely). Code is in the process of being deployed for this feature and it'd be nice if they didn't have to squat on something as part of deployment. > b) Draft is ready for WG LC: yes/no The draft has been generally stable, but seems to be getting the occasional tweaks in the face of reality. I'd suggest letting the implementors ask for that after any formal interop events shake out issues. WGLC done shortly thereafter would shake out any issues found in standards hopefully soon enough to not leave problems in the field too long. (C.f. aigp.) -- Jeff From rraszuk@gmail.com Fri Jan 17 08:46:10 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DEF71AE171 for ; Fri, 17 Jan 2014 08:46:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBI4i6-foqME for ; Fri, 17 Jan 2014 08:46:09 -0800 (PST) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 898991AE11E for ; Fri, 17 Jan 2014 08:46:07 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id ar20so928520iec.10 for ; Fri, 17 Jan 2014 08:45:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=iiW3DP0+zQTVUz787BUH+bKr7dn3/zWs0PnZx1y3tlw=; b=G4Ep4GkxsnWa994BhuERYVwCHzs8XBLDCyhkVaKwh+Aqf0I6f4wixvfnKWmz0vdtjv tORJnsDu1qiSVrSDH/gcUmlHxct+wkbfmQ8hqchUul0fSeOQ53kNlcVpI42Mt0sxSama lj6tFO0OKC8rL85A/YePAJKpCe3g38Lkeh5KDeCP4kQ564jy08EKVxHBcdBXoyz6U3Bm NJADgAiZfCkrTDhiM6djP1W8RHH4TO/dswka2ckzk6DVIexKvzjb0NybfR0hXLwAl/u8 NW8l3lB30OE4pDrY/Vt9AyKS1rGZ+OhllT9nFZOHT1jlCFA7yyBLrGfCvfCysrRtBLPV 72FQ== MIME-Version: 1.0 X-Received: by 10.50.87.201 with SMTP id ba9mr3569563igb.21.1389977154889; Fri, 17 Jan 2014 08:45:54 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.212.8 with HTTP; Fri, 17 Jan 2014 08:45:54 -0800 (PST) In-Reply-To: <00e301cf12b3$df905da0$9eb118e0$@ndzh.com> References: <00e301cf12b3$df905da0$9eb118e0$@ndzh.com> Date: Fri, 17 Jan 2014 17:45:54 +0100 X-Google-Sender-Auth: J4KtZ7lQjOEh0OlAcFxYLXdxTSY Message-ID: From: Robert Raszuk To: Susan Hares Content-Type: multipart/alternative; boundary=e89a8f3ba17d90314504f02d4665 Cc: idr wg , draft-ietf-idr-ls-distribution@tools.ietf.org Subject: Re: [Idr] WG LC - for early adoption Code points for draft-ietf-idr-ls-distribution-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 16:46:11 -0000 --e89a8f3ba17d90314504f02d4665 Content-Type: text/plain; charset=ISO-8859-1 a) Support early adoption: yes b) Draft is ready for WG LC: yes Thx, R. On Thu, Jan 16, 2014 at 1:09 PM, Susan Hares wrote: > Hi all > > > > In September 2013 the draft authors have asked for a WG LC on early > adoption code point. We had only 1 response for support. > > > > The authors have requested another WG LC on allowing this draft to have an > early adoption code-point. The authors point out that they are in multiple > vendor interoperability trials with 3+ implementations. > > > > This begins a 2 week WG LC on giving early code points to: > > > > https://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ > > > > > > Please comment on the list. It would aid the chairs if you would include > in your comments: > > > > a) Support early adoption: yes/no > > b) Draft is ready for WG LC: yes/no > > > > > > Sue and John > > Co-chairs > > > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --e89a8f3ba17d90314504f02d4665 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

a)= =A0=A0<= /span>Suppo= rt early adoption: yes

b)=A0=A0Draft is ready for WG LC: yes


Thx,

R.



On Thu, Jan 16, 2014 at 1:0= 9 PM, Susan Hares <shares@ndzh.com> wrote:

Hi all

= =A0

In September 2013 =A0the draft authors have ask= ed for a WG LC on early adoption code point. We had only 1 response for sup= port.

= =A0

The authors have requested another WG LC on all= owing this draft to have an early adoption code-point.=A0 The authors point= out that they are in multiple vendor interoperability trials with 3+ imple= mentations.

= =A0

This begins a 2 week WG LC on giving early code= points to:

= =A0

https://datatracker.ietf.or= g/doc/draft-ietf-idr-ls-distribution/

= =A0

=A0

Please comment on t= he list. It would aid the chairs if you would include in your comments: =

= =A0

a)=A0 Support early adoption: yes/no

b)=A0 = Draft is ready f= or WG LC: yes/no

= =A0

=A0

Sue and John

= Co-chairs =A0

=A0

=A0


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


--e89a8f3ba17d90314504f02d4665-- From jie.dong@huawei.com Fri Jan 17 09:59:45 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3721ADF78 for ; Fri, 17 Jan 2014 09:59:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rx7RJLLuVOYq for ; Fri, 17 Jan 2014 09:59:43 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 809D91AD939 for ; Fri, 17 Jan 2014 09:59:42 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCP42851; Fri, 17 Jan 2014 17:59:29 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 17 Jan 2014 17:58:39 +0000 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 17 Jan 2014 17:59:28 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.51]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Sat, 18 Jan 2014 01:59:20 +0800 From: "Dongjie (Jimmy)" To: Susan Hares , idr wg Thread-Topic: [Idr] WG Adoption call for draft-dong-idr-te-lsp-distribution Thread-Index: Ac8NUGUcV9wGRG4eS5qk8rMSu5JkuQGXTj2g Date: Fri, 17 Jan 2014 17:59:19 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927335C0A71@nkgeml512-mbx.china.huawei.com> References: <035201cf0d50$65cbbef0$31633cd0$@ndzh.com> In-Reply-To: <035201cf0d50$65cbbef0$31633cd0$@ndzh.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.192.198] Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C927335C0A71nkgeml512mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-dong-idr-te-lsp-distribution@tools.ietf.org" Subject: Re: [Idr] WG Adoption call for draft-dong-idr-te-lsp-distribution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 17:59:45 -0000 --_000_76CD132C3ADEF848BD84D028D243C927335C0A71nkgeml512mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support (as co-author). Best regards, Jie From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Thursday, January 09, 2014 6:35 PM To: idr wg Cc: draft-dong-idr-te-lsp-distribution@tools.ietf.org Subject: [Idr] WG Adoption call for draft-dong-idr-te-lsp-distribution IDR WG: This is to give a 2 week Call for adoption of: Distribution of MPLS Traffic Engineering (TE) LSP State using BGP draft-dong-idr-te-lsp-distribution-04 https://datatracker.ietf.org/doc/draft-dong-idr-te-lsp-distribution/ WG 2 week calls begins 1/9/14 and ends 1/22/14 Technical description: This document describes a mechanism to collect the Traffic Engineering (TE)= LSP information using BGP. Such information can be used by external compo= nents for path re-optimization, service placement and network visualization= . Sue and John IDR co-chairs --_000_76CD132C3ADEF848BD84D028D243C927335C0A71nkgeml512mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support (as co-author).

 

Best re= gards,

Jie

&n= bsp;

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Thursday, January 09, 2014 6:35 PM
To: idr wg
Cc: draft-dong-idr-te-lsp-distribution@tools.ietf.org
Subject: [Idr] WG Adoption call for draft-dong-idr-te-lsp-distributi= on

 

IDR WG:<= /p>

 

This is to give a 2 week C= all for adoption of:

 

Distribution of MPLS Traffic Engineering (TE) LSP State using BGP

draft-dong-idr-te-lsp-dist= ribution-04

 

https://datatracker.= ietf.org/doc/draft-dong-idr-te-lsp-distribution/

 

WG 2 week calls begins 1/9= /14 and ends 1/22/14

 

Technical description:

This document describes a mechanism to collect the Traffic Engineering (= TE) LSP information using BGP.  Such information can be used by external components for path re-optimization, service placement and net= work visualization.

 

 

Sue and John

IDR co-chairs

 

--_000_76CD132C3ADEF848BD84D028D243C927335C0A71nkgeml512mbxchi_-- From jie.dong@huawei.com Fri Jan 17 10:04:21 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CDAF1A16F0 for ; Fri, 17 Jan 2014 10:04:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VmQadi1iYiE for ; Fri, 17 Jan 2014 10:04:19 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 012141AC421 for ; Fri, 17 Jan 2014 10:04:18 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAB42037; Fri, 17 Jan 2014 18:04:06 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 17 Jan 2014 18:03:05 +0000 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 17 Jan 2014 18:04:05 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.51]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Sat, 18 Jan 2014 02:03:57 +0800 From: "Dongjie (Jimmy)" To: Susan Hares , idr wg Thread-Topic: [Idr] WG LC - for early adoption Code points for draft-ietf-idr-ls-distribution-04 Thread-Index: Ac8Ss7+puhBJmcAWS/ebVF4Sg9ldmwA+mb5A Date: Fri, 17 Jan 2014 18:03:56 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927335C0A9D@nkgeml512-mbx.china.huawei.com> References: <00e301cf12b3$df905da0$9eb118e0$@ndzh.com> In-Reply-To: <00e301cf12b3$df905da0$9eb118e0$@ndzh.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.192.198] Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C927335C0A9Dnkgeml512mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-ietf-idr-ls-distribution@tools.ietf.org" Subject: Re: [Idr] WG LC - for early adoption Code points for draft-ietf-idr-ls-distribution-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 18:04:21 -0000 --_000_76CD132C3ADEF848BD84D028D243C927335C0A9Dnkgeml512mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable a) Support early adoption: yes b) Draft is ready for WG LC: yes Best regards, Jie From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Thursday, January 16, 2014 3:10 PM To: idr wg Cc: draft-ietf-idr-ls-distribution@tools.ietf.org Subject: [Idr] WG LC - for early adoption Code points for draft-ietf-idr-ls= -distribution-04 Hi all In September 2013 the draft authors have asked for a WG LC on early adopti= on code point. We had only 1 response for support. The authors have requested another WG LC on allowing this draft to have an = early adoption code-point. The authors point out that they are in multiple= vendor interoperability trials with 3+ implementations. This begins a 2 week WG LC on giving early code points to: https://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ Please comment on the list. It would aid the chairs if you would include in= your comments: a) Support early adoption: yes/no b) Draft is ready for WG LC: yes/no Sue and John Co-chairs --_000_76CD132C3ADEF848BD84D028D243C927335C0A9Dnkgeml512mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

a)       Support early adoption: yes

&n= bsp;

b)       Draft is ready for WG LC: yes

 

Best re= gards,

Jie

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Thursday, January 16, 2014 3:10 PM
To: idr wg
Cc: draft-ietf-idr-ls-distribution@tools.ietf.org
Subject: [Idr] WG LC - for early adoption Code points for draft-ietf= -idr-ls-distribution-04

 

Hi all

 

In September 2013  the draft authors = have asked for a WG LC on early adoption code point. We had only 1 response= for support.

 

The authors have requested another WG LC o= n allowing this draft to have an early adoption code-point.  The autho= rs point out that they are in multiple vendor interoperability trials with 3+ implementations.

 

This begins a 2 week WG LC on giving early= code points to:

 

https://datatracker.ietf.org/doc/draft-i= etf-idr-ls-distribution/

 

 

Please comment on the list. It would aid t= he chairs if you would include in your comments:

 

a)<= span style=3D"font:7.0pt "Times New Roman"">  Support early adoption: yes/no

b)<= span style=3D"font:7.0pt "Times New Roman"">  Draft is ready for WG LC: yes/no

 

 

Sue and John

Co-chairs  

 

 

--_000_76CD132C3ADEF848BD84D028D243C927335C0A9Dnkgeml512mbxchi_-- From jeff.tantsura@ericsson.com Fri Jan 17 10:06:55 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D142A1AD73F for ; Fri, 17 Jan 2014 10:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDaAxnMNQynk for ; Fri, 17 Jan 2014 10:06:54 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id C5F4B1A16F0 for ; Fri, 17 Jan 2014 10:06:52 -0800 (PST) X-AuditID: c6180641-b7fbd8e0000011cc-94-52d97130cd0f Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 87.DD.04556.03179D25; Fri, 17 Jan 2014 19:06:40 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0347.000; Fri, 17 Jan 2014 13:06:39 -0500 From: Jeff Tantsura To: Susan Hares , idr wg Thread-Topic: [Idr] WG LC - for early adoption Code points for draft-ietf-idr-ls-distribution-04 Thread-Index: AQHPE67esSmPl94n8Eep1YLvtyB46Q== Date: Fri, 17 Jan 2014 18:06:38 +0000 Message-ID: In-Reply-To: <00e301cf12b3$df905da0$9eb118e0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_CEFEB10A43E06jefftantsuraericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXRPlK5B4c0gg4nnVSy2Pd3BZPHq9jMm iz9vXrE4MHssWfKTyWP26+usHl8uf2YLYI7isklJzcksSy3St0vgyjhy7wpjwd3AiiVHdzE1 MC726GLk4JAQMJF4vgLI5AQyxSQu3FvP1sXIxSEkcIRR4v27R8wQznJGiaV7VjCCVLEJGEj8 /3acBcQWEbCQWNo7kwnEZhZIldj35y0ziC0skCjR83c6G0RNksTlhSfYIWw9ibXzN4D1sgio Sjz/fRlsJq+AucTVK7vB4pxA9u3188DmMAJd9P3UGqj54hK3nsxngrhUQGLJnvPMELaoxMvH /1hBbFGg+W3HzrBDxJUlvs95xALyJLNAjMTZH5oQqwQlTs58wjKBUXQWkqmzEKpmIamCKDGQ eH9uPjOErS2xbOFrKFtfYuOXs4wQtrXEwn+7WZHVLGDkWMXIUVqcWpabbmS4iREYfcck2Bx3 MC74ZHmIUZqDRUmc98tb5yAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjEZ7/8pvu/L29Svu NRrnJJ9Wlionr5pR4XN7S3bbFt/lfx/xLhT0CbN+YsN0m0twdtCUwIV+6TvFpyZe5+D2uaQz 8+caaR6vW23t03MME4K+aHImNRQ/2srPxxH8yT13U9i7axG830SSLsYc0pxg8D+o8NopZjOt 5w05Bgd6BF9O76tnzShsUmIpzkg01GIuKk4EAJ+WxpOMAgAA Cc: "draft-ietf-idr-ls-distribution@tools.ietf.org" Subject: Re: [Idr] WG LC - for early adoption Code points for draft-ietf-idr-ls-distribution-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 18:06:56 -0000 --_000_CEFEB10A43E06jefftantsuraericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, A =96 yes B - yes Cheers, Jeff From: Susan Hares > Date: Thursday, January 16, 2014 4:09 AM To: idr wg > Cc: "draft-ietf-idr-ls-distribution@tools.ietf.org" > Subject: [Idr] WG LC - for early adoption Code points for draft-ietf-idr-ls= -distribution-04 Hi all In September 2013 the draft authors have asked for a WG LC on early adopti= on code point. We had only 1 response for support. The authors have requested another WG LC on allowing this draft to have an = early adoption code-point. The authors point out that they are in multiple= vendor interoperability trials with 3+ implementations. This begins a 2 week WG LC on giving early code points to: https://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ Please comment on the list. It would aid the chairs if you would include in= your comments: a) Support early adoption: yes/no b) Draft is ready for WG LC: yes/no Sue and John Co-chairs --_000_CEFEB10A43E06jefftantsuraericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <18EF185078A9A2499668A58A6B2FBDA5@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

A =96 yes
B - yes

Cheers,
Jeff

From: Susan Hares <shares@ndzh.com>
Date: Thursday, January 16, 2014 4:= 09 AM
To: idr wg <idr@ietf.org>
Cc: "draft-ietf-idr-ls-distribution@tool= s.ietf.org" <draft-ietf-idr-ls-distribution@tools.ietf.org>
Subject: [Idr] WG LC - for early ad= option Code points for draft-ietf-idr-ls-distribution-04

Hi all<= o:p>

&n= bsp;

In Sept= ember 2013  the draft authors have asked for a WG LC on early adoption= code point. We had only 1 response for support.

&n= bsp;

The aut= hors have requested another WG LC on allowing this draft to have an early a= doption code-point.  The authors point out that they are in multiple v= endor interoperability trials with 3+ implementations.

&n= bsp;

This be= gins a 2 week WG LC on giving early code points to:

&n= bsp;

https= ://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/<= /span>

&n= bsp;

&n= bsp;

Please = comment on the list. It would aid the chairs if you would include in your c= omments:

&n= bsp;

a)    &n= bsp;

&n= bsp;

Sue and= John

Co-chai= rs  

&n= bsp;

&n= bsp;

 --_000_CEFEB10A43E06jefftantsuraericssoncom_-- From internet-drafts@ietf.org Fri Jan 17 10:47:14 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFD61ADF7F; Fri, 17 Jan 2014 10:47:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZF3McjLB5Hh; Fri, 17 Jan 2014 10:47:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 40C501A1F55; Fri, 17 Jan 2014 10:47:13 -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: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140117184713.24941.19425.idtracker@ietfa.amsl.com> Date: Fri, 17 Jan 2014 10:47:13 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-flowspec-oid-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 18:47:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : Revised Validation Procedure for BGP Flow Specifi= cations Authors : James Uttaro Clarence Filsfils David Smith Juan Alcaide Pradosh Mohapatra Filename : draft-ietf-idr-bgp-flowspec-oid-02.txt Pages : 9 Date : 2014-01-17 Abstract: This document describes a modification to the validation procedure defined in RFC 5575 for the dissemination of BGP flow specifications. RFC 5575 requires that the originator of the flow specification matches the originator of the best-match unicast route for the destination prefix embedded in the flow specification. This allows only BGP speakers within the data forwarding path (such as autonomous system border routers) to originate BGP flow specifications. Though it is possible to disseminate such flow specifications directly from border routers, it may be operationally cumbersome in an autonomous system with a large number of border routers having complex BGP policies. The modification proposed herein enables flow specifications to be originated from a centralized BGP route controller. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-flowspec-oid/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-bgp-flowspec-oid-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-bgp-flowspec-oid-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From bill.wu@huawei.com Fri Jan 17 18:02:48 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35ABB1AD72A for ; Fri, 17 Jan 2014 18:02:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPUa9g9HLW7q for ; Fri, 17 Jan 2014 18:02:46 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 561411AC4A3 for ; Fri, 17 Jan 2014 18:02:45 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCP61794; Sat, 18 Jan 2014 02:02:31 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 18 Jan 2014 02:01:30 +0000 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 18 Jan 2014 02:02:30 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Sat, 18 Jan 2014 10:02:22 +0800 From: Qin Wu To: Robert Raszuk , Susan Hares Thread-Topic: [Idr] WG LC - for early adoption Code points for draft-ietf-idr-ls-distribution-04 Thread-Index: Ac8Ss7+puhBJmcAWS/ebVF4Sg9ldmwArMiMAACQssLA= Date: Sat, 18 Jan 2014 02:02:22 +0000 Message-ID: References: <00e301cf12b3$df905da0$9eb118e0$@ndzh.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA43C73E5Bnkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: idr wg , "draft-ietf-idr-ls-distribution@tools.ietf.org" Subject: Re: [Idr] WG LC - for early adoption Code points for draft-ietf-idr-ls-distribution-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2014 02:02:48 -0000 --_000_B8F9A780D330094D99AF023C5877DABA43C73E5Bnkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 Regards! -Qin From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: Saturday, January 18, 2014 12:46 AM To: Susan Hares Cc: idr wg; draft-ietf-idr-ls-distribution@tools.ietf.org Subject: Re: [Idr] WG LC - for early adoption Code points for draft-ietf-id= r-ls-distribution-04 a) Support early adoption: yes b) Draft is ready for WG LC: yes Thx, R. On Thu, Jan 16, 2014 at 1:09 PM, Susan Hares > wrote: Hi all In September 2013 the draft authors have asked for a WG LC on early adopti= on code point. We had only 1 response for support. The authors have requested another WG LC on allowing this draft to have an = early adoption code-point. The authors point out that they are in multiple= vendor interoperability trials with 3+ implementations. This begins a 2 week WG LC on giving early code points to: https://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ Please comment on the list. It would aid the chairs if you would include in= your comments: a) Support early adoption: yes/no b) Draft is ready for WG LC: yes/no Sue and John Co-chairs _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_B8F9A780D330094D99AF023C5877DABA43C73E5Bnkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1<= /p>

 <= /p>

Regards!

-Qin

 <= /p>

From: Idr [mai= lto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Saturday, January 18, 2014 12:46 AM
To: Susan Hares
Cc: idr wg; draft-ietf-idr-ls-distribution@tools.ietf.org
Subject: Re: [Idr] WG LC - for early adoption Code points for draft-= ietf-idr-ls-distribution-04

 

a)  = Support early adoption: yes=

b)  = Draft is ready for WG LC: yes

 

Thx,

R.

 

On Thu, Jan 16, 2014 at 1:09 PM, Susan Hares <shares@ndzh.com> w= rote:

Hi all

 

In September 2013  the draft authors have asked for a WG LC on ear= ly adoption code point. We had only 1 response for support.

 

The authors have requested another WG LC on allowing this draft to have= an early adoption code-point.  The authors point out that they are in multiple vendor interoperability trials with 3+ implementa= tions.

 

This begins a 2 week WG LC on giving early code points to:

 

https://datatracker.ietf.org/doc/draft-ietf-idr-ls-= distribution/

 

 

Please comment on the list. It would aid the chairs if you would includ= e in your comments:

 

a)=   b)=    

 

Sue and John

Co-chairs  

 

 


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

 

--_000_B8F9A780D330094D99AF023C5877DABA43C73E5Bnkgeml501mbschi_-- From ju1738@att.com Sat Jan 18 09:51:14 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DED11ADF7C for ; Sat, 18 Jan 2014 09:51:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcVrFvFZtAPP for ; Sat, 18 Jan 2014 09:51:12 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1911ADF7B for ; Sat, 18 Jan 2014 09:51:11 -0800 (PST) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id 30fbad25.2ba1914c1940.3329846.00-2421.9217923.nbfkord-smmo06.seg.att.com (envelope-from ); Sat, 18 Jan 2014 17:50:59 +0000 (UTC) X-MXL-Hash: 52dabf037221c9fe-f26108b99aed1152a4b4f754a573b9e44718018a Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id dfebad25.0.3329828.00-2041.9217876.nbfkord-smmo06.seg.att.com (envelope-from ); Sat, 18 Jan 2014 17:50:54 +0000 (UTC) X-MXL-Hash: 52dabefe50d6e2f6-e4bc112476365f01f9943031f0d6bc7630afa4da Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s0IHorIk004272; Sat, 18 Jan 2014 12:50:53 -0500 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s0IHomk4004247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Jan 2014 12:50:49 -0500 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (MISOUT7MSGHUB9D.itservices.sbc.com [144.151.223.93]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Sat, 18 Jan 2014 17:50:38 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.03.0174.001; Sat, 18 Jan 2014 12:50:38 -0500 From: "UTTARO, JAMES" To: "George, Wes" , Christopher Morrow Thread-Topic: [Idr] Question about draft: draft-ga-idr-as-migration-03.txt Thread-Index: Ac8SA40e7qKZlxliRMOMDETCRyUg8gCccYbg Date: Sat, 18 Jan 2014 17:50:36 +0000 Message-ID: References: <-4042749855639388205@gmail297201516> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.79.232] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=MLLXbrll c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=jHsTzGoMUScA:10 a=ofMgfj31e3cA:10 a=maGlnskHV9UA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=IkcTkHD0fZMA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=pVeHzU-_PH4A:10 a=48vgC7mUAAAA:8 a=K2syF1TXhAB9sG] X-AnalysisOut: [Q0Jg0A:9 a=QEXdDO2ut3YA:10 a=lZB815dzVvQA:10 a=PTsji3fnStM] X-AnalysisOut: [A:10 a=z_gJhoyQlVgIcMik:21 a=9AzgIOzF3T2GiRoB:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Cc: idr wg , Robert Raszuk Subject: Re: [Idr] Question about draft: draft-ga-idr-as-migration-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2014 17:51:14 -0000 SXQgd291bGQgc2VlbSB0byBtZSB0aGF0IHRoaXMgaXMgcHJpbWFyaWx5IGluZm9ybWF0aW9uYWwg aW4gbmF0dXJlLiBUaGVyZSBhcmUgb3RoZXIgbWV0aG9kcyBvZiBtYW5pcHVsYXRpbmcgQVMtUEFU SCBpLmUgQVNfT1ZFUlJJREUgdGhhdCBhcmUgdXNlZC4gQXMgdGhlc2UgdG9vbHMgYXJlIGFsc28g dXNlZCBpbiBvdGhlciBzcGFjZXMgaS5lIFZQTiBpdCB3b3VsZCBzZWVtIHBydWRlbnQgdG8gaW5j bHVkZSBvdGhlciB1c2UgY2FzZXMuLiBPbmUgaXMgdGhlIGFiaWxpdHkgdG8gaGF2ZSBtdWx0aXBs ZSBjdXN0b21lciBlbmRwb2ludHMgdXNpbmcgdGhlIHNhbWUgQVMgdG8gY29tbXVuaWNhdGUgb3Zl ciB0aGUgU1BzIG5ldHdvcmsuIEluIHRoaXMgY2FzZSBhbiBhcHByb2FjaCBtYXkgYmUgdG8gdXNl IEFTX09WRVJSSURFIHRvIGRpc2FibGUgdGhlIEFTX1BBVEggbG9vcCBwcmV2ZW50aW9uIG1ldGhv ZC4uICANCg0KSmltIFV0dGFybw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog SWRyIFttYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBHZW9yZ2UsIFdl cw0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDE1LCAyMDE0IDEwOjA4IEFNDQpUbzogQ2hyaXN0 b3BoZXIgTW9ycm93DQpDYzogaWRyIHdnOyBSb2JlcnQgUmFzenVrDQpTdWJqZWN0OiBSZTogW0lk cl0gUXVlc3Rpb24gYWJvdXQgZHJhZnQ6IGRyYWZ0LWdhLWlkci1hcy1taWdyYXRpb24tMDMudHh0 DQoNClRob3VnaHQgSSBzaG91bGQgbWF5YmUgd2VpZ2ggaW4gYXMgYW4gYXV0aG9yLi4uDQoNCg0K Pj4+IFdlbGwgdGhpcyBkcmFmdCBkaXNjdXNzZXMgYXBwbGljYWJpbGl0eSBvZiBsb2NhbC1hcywg bm8tcHJlcGVuZCBhbmQNCj4+PiByZXBsYWNlLWFzIGtub2JzLiBJDQo+Pg0KPj4gcmlnaHQsIHZl bmRvciBzcGVjaWZpYyBjb25maWd1cmF0aW9uIG9wdGlvbnMsIG5vdCBjaGFuZ2VzIHRvIHRoZSBi Z3ANCj4+IHByb3RvY29sIGl0c2VsZi4uLiBJIHRob3VnaHQuDQo+Pg0KVGhlIHN0YXRlZCBnb2Fs IGlzIHRvIGNvZGlmeSB0aGlzIGJlaGF2aW9yIGFzIGEgc3RhbmRhcmQgc28gdGhhdCBpdCBpcw0K Y2xlYXIgdGhhdCBmdXR1cmUgY2hhbmdlcyB0byBCR1AgbXVzdCBlaXRoZXIgc3VwcG9ydCB0aGlz IGZ1bmN0aW9uIG9yDQpleHBsaWNpdGx5IGdhaW4gY29uc2Vuc3VzIHRvIGRlcHJlY2F0ZS9icmVh ayBpdC4NCj4+DQo+Pj4gSU1PIGl0IGRvZXMgYmVsb25nIHRvIElEUiBhcyBpbXBsZW1lbnRhdGlv bnMgZmlyc3QgbmVlZCB0byBzdXBwb3J0IHN1Y2gNCj4+PiBrbm9icyBpbiBvcmRlciBmb3Igb3Bl cmF0b3JzIHRvIGRpc2N1c3MgaXRzIHVzZSBpbiBHUk9XLiBBbmQgZm9yIHRoYXQNCj4+PiBpbXBs ZW1lbnRvcnMgbmVlZCB0byB1bmRlcnN0YW5kIHRoZW0uIFdoaWxlIDMgcXVvdGVkIGltcGxlbWVu dGF0aW9ucw0KPj4+IHN1cHBvcnQgaXQgKGJldHRlciBvciB3b3JzZSA6KSB0aGVyZSBhcmUgbnVt YmVyIG9mIG90aGVyIEJHUCBjb2RlIGJhc2lzDQo+Pj4gd2hpY2ggc3RpbGwgZG8gbm90Lg0KPj4N Cj4+IHdhaXQsIHNvIG5vdyBJRFIgaXMgZ29pbmcgdG8gc3BlYyBpbXBsZW1lbnRhdGlvbiBrbm9i cz8gdGhhdCBzZWVtcyBsaWtlDQo+PiBpdCdzIG91dHNpZGUgb2YgdGhlIGNoYXJ0ZXIgdG8gbWUu Li4gb3IgcmF0aGVyIEkgZG9uJ3Qgc2VlIHRoaXMgaW4gdGhlDQo+Pmxpc3QNCj4+IG9mIHdvcmsg aXRlbXMgb3IgaW4gdGhlIGdlbmVyaWMgY2hhcnRlciBmbHVmZiBiZWZvcmUgd29yayBpdGVtcy4N Cj4+DQo+PiBpdCBzZWVtcyBtdWNoIG1vcmUgY2xlYXJseSB0byBmaXQgaW4gdGhlIGdyb3cgd29y bGQgdmlldy4uLiAobm90IHRoYXQgSQ0KPj4gd2FudCBtb3JlIHdvcmsgaW4gZ3JvdywgYnV0IHRo aXMganVzdCBkb2Vzbid0IHNlZW0gbGlrZSBJRFIgdG8NClRoaXMgaXMgYSBsaXR0bGUgaGlua3kg YXMg4oCccHJvdG9jb2wgd29ya+KAnSBiZWNhdXNlIGl04oCZcyBsb2NhbCBvbmx5LCByYXRoZXIN CnRoYW4gc29tZXRoaW5nIHRoYXQgcmVxdWlyZXMgaW50ZXJvcCBiZXR3ZWVuIEJHUCBzcGVha2Vy cyBhdCBhbg0KaW1wbGVtZW50YXRpb24gbGV2ZWwsIGJ1dCBhcyBub3RlZCwgU0lEUiB3YXMgYWJv dXQgdG8gaW50cm9kdWNlIHByb3RvY29sDQpjaGFuZ2VzIHRoYXQgd291bGQgaGF2ZSBicm9rZW4g aXQuIEluIHB1dHRpbmcgdGhpcyBkcmFmdCBpbnRvIElEUiwgSeKAmW0NCmdvaW5nIGJ5IHRoZSBy ZWNvbW1lbmRhdGlvbnMgZnJvbSB0aGUgZm9sa3MgaW52b2x2ZWQgaW4gU0lEUiAob2Ygd2hpY2gg dGhlDQpJRFIgb3ZlcmxhcCBpcyBub256ZXJvKSB0aGF0IGluIG9yZGVyIHRvIGV4cGVjdCBTSURS IHRvIGNoYW5nZSB0aGUgQkdQU2VjDQpkZXNpZ24gZm9yIHNvbWV0aGluZyB0aGF0IGlzIGhlYXZp bHkgdXNlZCBidXQgbm90IHRlY2huaWNhbGx5IHBhcnQgb2YgdGhlDQpCR1AgU3BlYywgaXQgcmVh bGx5IHNob3VsZCBiZSBzdGFuZGFyZGl6ZWQgZmlyc3QsIGFuZCBJRFIgaXMgd2hlcmUgQkdQDQpw cm90b2NvbCB3b3JrIGlzIGRvbmUuIEhlbmNlIHRoZSBkZXBlbmRlbnQgbm9ybWF0aXZlIHJlZmVy ZW5jZSBiZXR3ZWVuDQpkcmFmdC1pZXRmLXNpZHItYXMtbWlncmF0aW9uIGFuZCB0aGlzIGRyYWZ0 Lg0KSeKAmW0gb3BlbiB0byBwdXR0aW5nIGl0IGluIEdST1cgaWYgdGhhdOKAmXMgd2hlcmUgaXQg bWFrZXMgbW9yZSBzZW5zZSwganVzdA0KbmVlZCBzb21lIHNvbGlkIGRpcmVjdGlvbiBvbmUgd2F5 IG9yIHRoZSBvdGhlci4NCg0KVGhhbmtzDQpXZXMgR2VvcmdlDQoNCg0KDQpBbnl0aGluZyBiZWxv dyB0aGlzIGxpbmUgaGFzIGJlZW4gYWRkZWQgYnkgbXkgY29tcGFueeKAmXMgbWFpbCBzZXJ2ZXIs IEkNCmhhdmUgbm8gY29udHJvbCBvdmVyIGl0Lg0KLS0tLS0tLS0tLS0NCg0KDQpUaGlzIEUtbWFp bCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJs ZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50 aWFsLCBvciBzdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2Fi bGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5k aXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBu b3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9y IGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1l bnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxh d2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBv cmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZHIgbWFpbGlu ZyBsaXN0DQpJZHJAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaWRyDQo= From william.mccall@gmail.com Mon Jan 20 11:38:59 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1441A025D for ; Mon, 20 Jan 2014 11:38:59 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63QQQDr7zOW4 for ; Mon, 20 Jan 2014 11:38:57 -0800 (PST) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 663791A01F1 for ; Mon, 20 Jan 2014 11:38:57 -0800 (PST) Received: by mail-vc0-f171.google.com with SMTP id le5so3106227vcb.30 for ; Mon, 20 Jan 2014 11:38:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=freU3eMc51qEisuwC0AcsMcFCBkiOuV58A5xAsa3w3E=; b=T00mumlYZIC6y3ZMKW1wb7+VERR+5DBABK+XY4RrY4lkzL2hQoH3myr1SeHLNucOnF tAQvFC1upIQump5YK8SDKFX0ZXYbHjkD5fn9sEEsyhIag8FXnPAEZxogYw0eWPPVT17F JVXzpL57n4Y38du9Fqm2mjDzQOzzKxYgmu60ndaf4b2kPiByt62TmFX49Tdd9l70XgfZ 375VQKKvPV87SYA/f4g3Nsj3Kh1+/Hg78lG7sp6qFe34K60DAnyOCiHhiFRGM3Xjgq// Xpyyu6w+CEIgiZOT0UOKX9uu0Jw3hhQl90IfmJEieI1Af3pGQDOJ/4ZTwAzplq8VpnRW S9Lg== MIME-Version: 1.0 X-Received: by 10.58.85.133 with SMTP id h5mr11332187vez.4.1390246737383; Mon, 20 Jan 2014 11:38:57 -0800 (PST) Received: by 10.220.58.67 with HTTP; Mon, 20 Jan 2014 11:38:57 -0800 (PST) Date: Mon, 20 Jan 2014 19:38:57 +0000 Message-ID: From: William McCall To: idr@ietf.org Content-Type: multipart/alternative; boundary=047d7b86f0baee96ff04f06c0ae0 Subject: [Idr] [Technical Errata Reported] RFC4271 (3673) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 19:38:59 -0000 --047d7b86f0baee96ff04f06c0ae0 Content-Type: text/plain; charset=ISO-8859-1 Hello all-- I am following up this proposed erratum since it recently noticed it got rejected and the verification does not match the proposed erratum. I am looking into clarification of the verification and/or maybe accepting this erratum. The proposed erratum (very nitpicky, apologies in advance) concerns the listing of the types of path attributes in section 5. In it, it states that path attributes are either well known mandatory, discretionary, optional transitive or optional non-transitive. There is a distinct exception which I call out to LOCAL_PREF which is neither well known mandatory nor well known discretionary (but certainly well known per its definition in 5.1.5). As such, my proposal is to correct the list to include simply "well-known" as an attribute type. An alternative could be to call out the special categorization of LOCAL_PREF after the list or something similar. In the verification, the reason for rejection is: "-- --VERIFIER NOTES-- This erratum was discussed on the IDR list. The consensus was that whilst an alternative is to revert from OpenSent to Idle on event 18 at that point, this was not what was decided when RFC4271 was being produced, and no one saw a good engineering reason to change it at this stage. On a matter of process, this proposal is not an Erratum as the IETF sees it but an engineering change. The submitter is, of course, welcome to submit a draft proposing this change to RFC 4271 and the to discuss the merits of the change with the IDR Working Group. " This verification is inappropriate for a few reasons: 1) Errata 3673 has never been discussed on list. 2) OpenSent is not a state that a speaker will be in when sending or receiving updates 3) Event 18 is for TcpConnectionFails, which is never addressed nor particularly relevant to path attributes. It appears that this verification was intended for erratum 3366, which is the one that is before the one I submitted in the list. It does address the behavior in OpenSent when event 18 occurs. So, my questions for the list are: 1) Does this verification look incorrect? If not can this be corrected with the consensus? 2) Is the proposed erratum intended to be rejected? Thanks! -- William McCall --047d7b86f0baee96ff04f06c0ae0 Content-Type: text/html; charset=ISO-8859-1
Hello all--

I am following up this proposed erratum since it recently noticed it got rejected and the verification does not match the proposed erratum. I am looking into clarification of the verification and/or maybe accepting this erratum.

The proposed erratum (very nitpicky, apologies in advance) concerns the listing of the types of path attributes in section 5. In it, it states that path attributes are either well known mandatory, discretionary, optional transitive or optional non-transitive.

There is a distinct exception which I call out to LOCAL_PREF which is neither well known mandatory nor well known discretionary (but certainly well known per its definition in 5.1.5). As such, my proposal is to correct the list to include simply "well-known" as an attribute type. An alternative could be to call out the special categorization of LOCAL_PREF after the list or something similar.

In the verification, the reason for rejection is:

"-- --VERIFIER NOTES--
This erratum was discussed on the IDR list.

The consensus was that whilst an alternative is to revert
from OpenSent to Idle on event 18 at that point, this was not
what was decided when RFC4271 was being produced, and
no one saw a good engineering reason to change it at this
stage.

On a matter of process, this proposal is not an Erratum
as the IETF sees it but an engineering change.

The submitter is, of course, welcome to submit a draft
proposing this change to RFC 4271 and the to discuss the
merits of the change with the IDR Working Group. "

This verification is inappropriate for a few reasons:

1) Errata 3673 has never been discussed on list.
2) OpenSent is not a state that a speaker will be in when sending or receiving updates
3) Event 18 is for TcpConnectionFails, which is never addressed nor particularly relevant to path attributes.

It appears that this verification was intended for erratum 3366, which is the one that is before the one I submitted in the list. It does address the behavior in OpenSent when event 18 occurs.

So, my questions for the list are:

1) Does this verification look incorrect? If not can this be corrected with the consensus?
2) Is the proposed erratum intended to be rejected?


Thanks!

--
William McCall
--047d7b86f0baee96ff04f06c0ae0-- From jakob.heitz@ericsson.com Mon Jan 20 12:58:18 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 479361A0254 for ; Mon, 20 Jan 2014 12:58:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCdpK7bm8lhx for ; Mon, 20 Jan 2014 12:58:16 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 443D71A024D for ; Mon, 20 Jan 2014 12:58:16 -0800 (PST) X-AuditID: c6180641-b7fbd8e0000011cc-2c-52dd8de8510a Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 99.CE.04556.8ED8DD25; Mon, 20 Jan 2014 21:58:16 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0387.000; Mon, 20 Jan 2014 15:58:15 -0500 From: Jakob Heitz To: Susan Hares , idr wg Thread-Topic: [Idr] WG Adoption call for draft-dong-idr-te-lsp-distribution Thread-Index: Ac8NUGUcV9wGRG4eS5qk8rMSu5JkuQI0ehWw Date: Mon, 20 Jan 2014 20:58:15 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F4E40F@eusaamb109.ericsson.se> References: <035201cf0d50$65cbbef0$31633cd0$@ndzh.com> In-Reply-To: <035201cf0d50$65cbbef0$31633cd0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_2F3EBB88EC3A454AAB08915FBF0B8C7E02F4E40Feusaamb109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyuXRPuO6L3rtBBn9aTCxu7XrKbPHq9jMm iz9vXrE4MHssWfKTyWP26+usHl8uf2YLYI7isklJzcksSy3St0vgyri96AJLwQfLipdnFRoY W026GDk4JARMJDZNt+ti5AQyxSQu3FvP1sXIxSEkcIRR4kHjSiaQhJDAckaJdQfyQGw2AR2J b9e7mEFsEQELiaW9M8FqmAVyJc7cm8AOYgsLeElcnfeKBaLGW+LD4gNMELaRxIv1W8F6WQRU JV4fOs8GYvMK+ErMPPkCapeZxIubq1hBbE4Bc4nOF1vAahiBjvt+ag3ULnGJW0/mM0EcLSCx ZM95ZghbVOLl43+sELaSxKSl51gh6vMlZp/fyQKxS1Di5MwnLBMYRWchGTULSdksJGUQcR2J Bbs/sUHY2hLLFr5mhrHPHHjMhCy+gJF9FSNHaXFqWW66keEmRmCUHZNgc9zBuOCT5SFGaQ4W JXHeL2+dg4QE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwuuad7nofoOlatfrpLj/nez48cukV rXkdc1uiBc2cGU7dqre+Xh4rc3tN8/zDag979whln11/5llTfOYvBls+p33m65pkHe19ub5c ydofXdGqeuRayzM7v2NOXlritbopehfMPvZW3tOuWH17ooqHrIxPbb1KO/vUvE8dHjcMr988 Zj37/TolluKMREMt5qLiRADdCJAMgAIAAA== Cc: "draft-dong-idr-te-lsp-distribution@tools.ietf.org" Subject: Re: [Idr] WG Adoption call for draft-dong-idr-te-lsp-distribution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 20:58:18 -0000 --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E02F4E40Feusaamb109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. Thanks, Jakob. From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Thursday, January 09, 2014 7:35 AM To: idr wg Cc: draft-dong-idr-te-lsp-distribution@tools.ietf.org Subject: [Idr] WG Adoption call for draft-dong-idr-te-lsp-distribution IDR WG: This is to give a 2 week Call for adoption of: Distribution of MPLS Traffic Engineering (TE) LSP State using BGP draft-dong-idr-te-lsp-distribution-04 https://datatracker.ietf.org/doc/draft-dong-idr-te-lsp-distribution/ WG 2 week calls begins 1/9/14 and ends 1/22/14 Technical description: This document describes a mechanism to collect the Traffic Engineering (TE)= LSP information using BGP. Such information can be used by external compo= nents for path re-optimization, service placement and network visualization= . Sue and John IDR co-chairs --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E02F4E40Feusaamb109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support.

 

Thanks,

Jakob.

 

From: Idr [mai= lto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Thursday, January 09, 2014 7:35 AM
To: idr wg
Cc: draft-dong-idr-te-lsp-distribution@tools.ietf.org
Subject: [Idr] WG Adoption call for draft-dong-idr-te-lsp-distributi= on

 

IDR WG:

 

This is to give a 2 week Call for adoption of:

 

Distribution of MPLS Traffic E= ngineering (TE) LSP State using BGP

draft-dong-idr-te-lsp-distribution-04

 

https://datatracker.ietf.org/doc/draft-dong-idr-te-ls= p-distribution/

 

WG 2 week calls begins 1/9/14 and ends 1/22/14

 

Technical description:

This document describes a mech= anism to collect the Traffic Engineering (TE) LSP information using BGP.&nb= sp; Such information can be used by external components for path re-optimization, service placement and network visualization.

 

 

Sue and John

IDR co-chairs

 

--_000_2F3EBB88EC3A454AAB08915FBF0B8C7E02F4E40Feusaamb109erics_-- From sprevidi@cisco.com Mon Jan 20 23:56:25 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD831A0054 for ; Mon, 20 Jan 2014 23:56:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8E5O994doCra for ; Mon, 20 Jan 2014 23:56:24 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id A797B1A0020 for ; Mon, 20 Jan 2014 23:56:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=871; q=dns/txt; s=iport; t=1390290985; x=1391500585; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+hUJkELKNYiS44U3TVZI/rIc3t5wyOufr4Tiiyj1CwA=; b=InPvLONszEKNZb40kk/cBc4GsUZv1a68jxLc0KzB4vW3+9MBgdBgiPz8 ilIdHijbCafMXnULD68B3Ss53UPPdA3m11iWyCob8fLNQjBrffUM7pMv0 vtg+pJihQdK2euDPlzbVzPkIJQstzZjSkQ+TrdqNoUti/RCo8ivRW5pME 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAMsn3lKtJXG//2dsb2JhbABZgws4VrtdgQ4WdIIlAQEBAwEBAQEaHTQLBQsCAQgOKBAnCyUCBA4Fh30IDcN3EwSOTDMHgySBFASYIpIYgy2CKg X-IronPort-AV: E=Sophos;i="4.95,695,1384300800"; d="scan'208";a="298572593" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 21 Jan 2014 07:56:24 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0L7uOh2010557 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jan 2014 07:56:24 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.207]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Tue, 21 Jan 2014 01:56:24 -0600 From: "Stefano Previdi (sprevidi)" To: Susan Hares Thread-Topic: [Idr] WG Adoption call for draft-dong-idr-te-lsp-distribution Thread-Index: AQHPFn5HV9wGRG4eS5qk8rMSu5JkuQ== Date: Tue, 21 Jan 2014 07:56:24 +0000 Message-ID: <4FE7BF60-32B8-46AD-8D71-85DE15D042D8@cisco.com> References: <035201cf0d50$65cbbef0$31633cd0$@ndzh.com> In-Reply-To: <035201cf0d50$65cbbef0$31633cd0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.88.102] Content-Type: text/plain; charset="us-ascii" Content-ID: <72508A83DD9C8048B9D7643A1C78E9AF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: idr wg , "" Subject: Re: [Idr] WG Adoption call for draft-dong-idr-te-lsp-distribution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 07:56:26 -0000 support as co-author. thanks. s. On Jan 9, 2014, at 4:35 PM, Susan Hares wrote: > IDR WG: > =20 > This is to give a 2 week Call for adoption of: > =20 > Distribution of MPLS Traffic Engineering (TE) LSP State using BGP > draft-dong-idr-te-lsp-distribution-04 > =20 > https://datatracker.ietf.org/doc/draft-dong-idr-te-lsp-distribution/ > =20 > WG 2 week calls begins 1/9/14 and ends 1/22/14 > =20 > Technical description: > This document describes a mechanism to collect the Traffic Engineering (T= E) LSP information using BGP. Such information can be used by external com= ponents for path re-optimization, service placement and network visualizati= on. > =20 > =20 > Sue and John > IDR co-chairs > =20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From hannes@juniper.net Tue Jan 21 01:46:56 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B929C1A00A2 for ; Tue, 21 Jan 2014 01:46:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hj1TetW6mh1p for ; Tue, 21 Jan 2014 01:46:54 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id 91B301A0087 for ; Tue, 21 Jan 2014 01:46:54 -0800 (PST) Received: from mail10-co1-R.bigfish.com (10.243.78.230) by CO1EHSOBE036.bigfish.com (10.243.66.101) with Microsoft SMTP Server id 14.1.225.22; Tue, 21 Jan 2014 09:46:53 +0000 Received: from mail10-co1 (localhost [127.0.0.1]) by mail10-co1-R.bigfish.com (Postfix) with ESMTP id F16355802F0; Tue, 21 Jan 2014 09:46:53 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.234.117; KIP:(null); UIP:(null); IPV:NLI; H:SN2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 11 X-BigFish: VPS11(z3eddszda00hdc73hzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzzz2fh2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e23h1fe8h1ff5h2052h20b3h2218h2216h226dh22d0h24afh2327h2336h2438h2461h2487h1155h) Received-SPF: pass (mail10-co1: domain of juniper.net designates 157.56.234.117 as permitted sender) client-ip=157.56.234.117; envelope-from=hannes@juniper.net; helo=SN2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail10-co1 (localhost.localdomain [127.0.0.1]) by mail10-co1 (MessageSwitch) id 1390297611891839_10405; Tue, 21 Jan 2014 09:46:51 +0000 (UTC) Received: from CO1EHSMHS014.bigfish.com (unknown [10.243.78.247]) by mail10-co1.bigfish.com (Postfix) with ESMTP id CBCE8A4004A; Tue, 21 Jan 2014 09:46:51 +0000 (UTC) Received: from SN2PRD0510HT005.namprd05.prod.outlook.com (157.56.234.117) by CO1EHSMHS014.bigfish.com (10.243.66.24) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 21 Jan 2014 09:46:47 +0000 Received: from [172.29.67.100] (193.110.55.18) by pod51010.outlook.com (10.255.116.40) with Microsoft SMTP Server (TLS) id 14.16.395.1; Tue, 21 Jan 2014 09:46:46 +0000 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="us-ascii" From: Hannes Gredler In-Reply-To: <4FE7BF60-32B8-46AD-8D71-85DE15D042D8@cisco.com> Date: Tue, 21 Jan 2014 10:46:41 +0100 Content-Transfer-Encoding: 7bit Message-ID: References: <035201cf0d50$65cbbef0$31633cd0$@ndzh.com> <4FE7BF60-32B8-46AD-8D71-85DE15D042D8@cisco.com> To: idr wg X-Mailer: Apple Mail (2.1283) X-Originating-IP: [193.110.55.18] X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Susan Hares , draft-dong-idr-te-lsp-distribution@tools.ietf.org Subject: Re: [Idr] WG Adoption call for draft-dong-idr-te-lsp-distribution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 09:46:56 -0000 support (as co-author) /hannes From rraszuk@gmail.com Tue Jan 21 01:53:23 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7208A1A00A0 for ; Tue, 21 Jan 2014 01:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRCcAMUWuOzc for ; Tue, 21 Jan 2014 01:53:22 -0800 (PST) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id D42C11A0087 for ; Tue, 21 Jan 2014 01:53:21 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id e14so9590942iej.31 for ; Tue, 21 Jan 2014 01:53:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=FdnTwBculA0Kg9CfIINfzsnsqf6tHDBhaapAvAHqixc=; b=lqyvq8da9bfQZonkIBh/u5km/ZWoc6V5v8nC7dJ+DzrRXeT+dv8SnZQ2StLm4PJI0c sTWLGHWLUCfLqGBLAFswJH2qQ/PltcRh/UgoLr2L9VYR63fn2ocUmmqwdybOs6BwySY8 77kw/jv7/wbpqX9BJv5AiRNb4+3nYzzZ6W6yWGkn1uvt65w5wpN0TXPqb7ptqjTxBUTQ EPWPwFqocHMZOIz4wguU2kqSW6m2zOL9SORSepvRto5YMv9sx8l2i2vEy4RN9buukXtr UWBn+220ZmVabL//VswBrdFzDxi5dC6wafgdTEXFmjlnRDfjJee4RbWDFbbMQUkSciQ5 w1AQ== MIME-Version: 1.0 X-Received: by 10.42.40.83 with SMTP id k19mr17141495ice.3.1390298000700; Tue, 21 Jan 2014 01:53:20 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.212.8 with HTTP; Tue, 21 Jan 2014 01:53:20 -0800 (PST) In-Reply-To: <035201cf0d50$65cbbef0$31633cd0$@ndzh.com> References: <035201cf0d50$65cbbef0$31633cd0$@ndzh.com> Date: Tue, 21 Jan 2014 10:53:20 +0100 X-Google-Sender-Auth: y-iigfjwDC01MLIu1cdBAdSmdzI Message-ID: From: Robert Raszuk To: Susan Hares Content-Type: multipart/alternative; boundary=90e6ba1efbf476b8d004f077fa03 Cc: idr wg , draft-dong-idr-te-lsp-distribution@tools.ietf.org Subject: Re: [Idr] WG Adoption call for draft-dong-idr-te-lsp-distribution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 09:53:23 -0000 --90e6ba1efbf476b8d004f077fa03 Content-Type: text/plain; charset=ISO-8859-1 Support. Rgs, R On Thu, Jan 9, 2014 at 4:35 PM, Susan Hares wrote: > IDR WG: > > > > This is to give a 2 week Call for adoption of: > > > > Distribution of MPLS Traffic Engineering (TE) LSP State using BGP > > draft-dong-idr-te-lsp-distribution-04 > > > > https://datatracker.ietf.org/doc/draft-dong-idr-te-lsp-distribution/ > > > > WG 2 week calls begins 1/9/14 and ends 1/22/14 > > > > *Technical description: * > > This document describes a mechanism to collect the Traffic Engineering > (TE) LSP information using BGP. Such information can be used by external > components for path re-optimization, service placement and network > visualization. > > > > > > Sue and John > > IDR co-chairs > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --90e6ba1efbf476b8d004f077fa03 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Support.

Rgs,
R


On Thu, Jan 9, 2014 at 4:35 PM, Susan Hares <<= a href=3D"mailto:shares@ndzh.com" target=3D"_blank">shares@ndzh.com>= wrote:

IDR WG:

=A0

This is to give= a 2 week Call for adoption of:

=A0

Distribution of MPLS Traffic Engineering (TE) LSP State using= BGP

draft-dong-idr-te-lsp-distribution-04<= /p>

=A0

https://datatracker.ietf.org/doc/dr= aft-dong-idr-te-lsp-distribution/

=A0

WG 2 week calls= begins 1/9/14 and ends 1/22/14

=A0

Technical description:

This document describes a mech= anism to collect the Traffic Engineering (TE) LSP information using BGP.=A0= Such information can be used by external components for path re-optimizati= on, service placement and network visualization.

=A0

=A0

Sue and John

IDR co-chairs <= u>

=A0


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


--90e6ba1efbf476b8d004f077fa03-- From jmedved@cisco.com Tue Jan 21 03:14:17 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10F051A00AE for ; Tue, 21 Jan 2014 03:14:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.035 X-Spam-Level: X-Spam-Status: No, score=-15.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWvlsrboVuLb for ; Tue, 21 Jan 2014 03:14:15 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 502A31A009D for ; Tue, 21 Jan 2014 03:14:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5454; q=dns/txt; s=iport; t=1390302855; x=1391512455; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XgT195nFBsRcXfdSA6hsxaIjw+Btu5Nxbxvo7cexOxo=; b=DXc6Ncwtd9/d/zEfZ4mNSzI1Tz41REWyAYTBAj9MZgR+mMF/SZ7UDdMB BYjGmD4vwkmUYKmF2zyZWJqiHGHJhBxmv/I+8fjAl07Y36kOTJm7fYkRH Y7Fu4m6ASfozWHCTrOZRbXjoNJt+PwG2vBKei4kIRoSXtSl77prt0JoEv E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAFhV3lKtJXG//2dsb2JhbABZgkdEOFa7ZoESFnSCJgEBBAEBARpRCxACAQgOMQcnCxQRAgQOBYgFDcN7EwSOewQGAYQ4BJgikhiDLYIq X-IronPort-AV: E=Sophos;i="4.95,695,1384300800"; d="scan'208,217";a="298641460" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 21 Jan 2014 11:14:15 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0LBEEA2001112 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jan 2014 11:14:14 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.18]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Tue, 21 Jan 2014 05:14:14 -0600 From: "Jan Medved (jmedved)" To: Susan Hares Thread-Topic: [Idr] WG Adoption call for draft-dong-idr-te-lsp-distribution Thread-Index: AQHPFo6dV9wGRG4eS5qk8rMSu5JkuZqO5S4A Date: Tue, 21 Jan 2014 11:14:13 +0000 Message-ID: References: <035201cf0d50$65cbbef0$31633cd0$@ndzh.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.86.254.232] Content-Type: multipart/alternative; boundary="_000_CF0396633A60Ejmedvedciscocom_" MIME-Version: 1.0 Cc: idr wg , "draft-dong-idr-te-lsp-distribution@tools.ietf.org" Subject: Re: [Idr] WG Adoption call for draft-dong-idr-te-lsp-distribution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 11:14:17 -0000 --_000_CF0396633A60Ejmedvedciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. /Jan Medved On Thu, Jan 9, 2014 at 4:35 PM, Susan Hares > wrote: IDR WG: This is to give a 2 week Call for adoption of: Distribution of MPLS Traffic Engineering (TE) LSP State using BGP draft-dong-idr-te-lsp-distribution-04 https://datatracker.ietf.org/doc/draft-dong-idr-te-lsp-distribution/ WG 2 week calls begins 1/9/14 and ends 1/22/14 Technical description: This document describes a mechanism to collect the Traffic Engineering (TE)= LSP information using BGP. Such information can be used by external compo= nents for path re-optimization, service placement and network visualization= . Sue and John IDR co-chairs _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_CF0396633A60Ejmedvedciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Support.


/Jan Medved


On Thu, Jan 9, 2014 at 4:35 PM, Susan Hares <shares@ndzh.com> wrote:

IDR WG:

 

This is to give a 2 week Call for adoption of:

 

Distribution of MPLS Traffic Engineeri= ng (TE) LSP State using BGP

draft-dong-idr-te-lsp-distribution-04

 

https://datatracker.ietf.org/doc/draft-dong= -idr-te-lsp-distribution/

 

WG 2 week calls begins 1/9/14 and ends 1/22/14=

 

Technical description:

This document describes a mechanism to= collect the Traffic Engineering (TE) LSP information using BGP.  Such= information can be used by external components for path re-optimization, service placement and network visualization.<= /u>

 

 

Sue and John

IDR co-chairs

 


_______________________________________________

Idr mailing list





 --_000_CF0396633A60Ejmedvedciscocom_-- From keyupate@cisco.com Tue Jan 21 09:58:40 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 211611A03E9 for ; Tue, 21 Jan 2014 09:58:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRLG5D7iKHAh for ; Tue, 21 Jan 2014 09:58:38 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB521A01D7 for ; Tue, 21 Jan 2014 09:58:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7600; q=dns/txt; s=iport; t=1390327118; x=1391536718; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=DYC7lvpohrCdiqDNfP3BFJAI0yxYPuwIytiurk0j1vQ=; b=S9F1AMy0soJRLfkgBuM1csGUWNViYzKhosFY+a35Dp3Gdm2zzLQthUiN hUrNAvqXl6rrqQvRMuqPsrdUjzKz6eoWLoEHkhHyY4jZGGCOGSn1YjmjF Xpc/Bbd3N1xun7XKeLkjrV1KfaCsnt95a3cqUxEgDIVZFOh66/Dki1aRl c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAEO03lKtJXHA/2dsb2JhbABZgkdEOFa7bYEUFnSCJQEBAQQBAQEaEEELEgEIDgMDAQIoLgsUCQgCBAENBYgFDcNBEwSObg0EBgGEOASYIpIYgy2CKg X-IronPort-AV: E=Sophos;i="4.95,696,1384300800"; d="scan'208,217";a="14429599" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-5.cisco.com with ESMTP; 21 Jan 2014 17:58:38 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s0LHwbbR014969 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jan 2014 17:58:37 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.228]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Tue, 21 Jan 2014 11:58:37 -0600 From: "Keyur Patel (keyupate)" To: Susan Hares , idr wg Thread-Topic: [Idr] WG Adoption call for draft-dong-idr-te-lsp-distribution Thread-Index: AQHPFtJoV9wGRG4eS5qk8rMSu5JkuQ== Date: Tue, 21 Jan 2014 17:58:36 +0000 Message-ID: In-Reply-To: <035201cf0d50$65cbbef0$31633cd0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [128.107.163.49] Content-Type: multipart/alternative; boundary="_000_CF03F6485FD36keyupateciscocom_" MIME-Version: 1.0 Cc: "draft-dong-idr-te-lsp-distribution@tools.ietf.org" Subject: Re: [Idr] WG Adoption call for draft-dong-idr-te-lsp-distribution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 17:58:40 -0000 --_000_CF03F6485FD36keyupateciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. Regards, Keyur From: Susan Hares > Date: Thu, 9 Jan 2014 10:35:16 -0500 To: idr wg > Cc: > Subject: [Idr] WG Adoption call for draft-dong-idr-te-lsp-distribution IDR WG: This is to give a 2 week Call for adoption of: Distribution of MPLS Traffic Engineering (TE) LSP State using BGP draft-dong-idr-te-lsp-distribution-04 https://datatracker.ietf.org/doc/draft-dong-idr-te-lsp-distribution/ WG 2 week calls begins 1/9/14 and ends 1/22/14 Technical description: This document describes a mechanism to collect the Traffic Engineering (TE)= LSP information using BGP. Such information can be used by external compo= nents for path re-optimization, service placement and network visualization= . Sue and John IDR co-chairs _______________________________________________ Idr mailing list Idr@ietf.o= rg https://www.ietf.org/mailman/listinfo/idr --_000_CF03F6485FD36keyupateciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <83C688DE140E924EAAF59C0007783114@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Support.

Regards,
Keyur

From: Susan Hares <shares@ndzh.com>
Date: Thu, 9 Jan 2014 10:35:16 -050= 0
To: idr wg <idr@ietf.org>
Cc: <draft-dong-idr-te-lsp-distributio= n@tools.ietf.org>
Subject: [Idr] WG Adoption call for= draft-dong-idr-te-lsp-distribution

IDR WG:

 

This is to give a 2 week Call for adoption of:

 

Distribution of MPLS Traffic Engineer= ing (TE) LSP State using BGP

draft-dong-idr-te-lsp-distribution-04

 

https://datatracker.ietf.org/doc/draft-dong-idr-te-lsp-distr= ibution/

 

WG 2 week calls begins 1/9/14 and ends 1/22/14

 

Technical description:

This document describes a mechanism t= o collect the Traffic Engineering (TE) LSP information using BGP.  Suc= h information can be used by external components for path re-optimization, service placement and network visualization.

 

 

Sue and John

IDR co-chairs

 

_______________________________________________ Idr mailing list Idr@ietf.org http= s://www.ietf.org/mailman/listinfo/idr --_000_CF03F6485FD36keyupateciscocom_-- From jhaas@slice.pfrc.org Tue Jan 21 12:32:00 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 872391A01C2 for ; Tue, 21 Jan 2014 12:32:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80FkHtv8di9U for ; Tue, 21 Jan 2014 12:31:59 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0CABF1A01B3 for ; Tue, 21 Jan 2014 12:31:59 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id C4E1BC17E; Tue, 21 Jan 2014 15:31:58 -0500 (EST) Date: Tue, 21 Jan 2014 15:31:58 -0500 From: Jeffrey Haas To: Susan Hares Message-ID: <20140121203158.GH4366@pfrc> References: <035201cf0d50$65cbbef0$31633cd0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <035201cf0d50$65cbbef0$31633cd0$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: idr wg , draft-dong-idr-te-lsp-distribution@tools.ietf.org Subject: Re: [Idr] WG Adoption call for draft-dong-idr-te-lsp-distribution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 20:32:00 -0000 On Thu, Jan 09, 2014 at 10:35:16AM -0500, Susan Hares wrote: > IDR WG: > > This is to give a 2 week Call for adoption of: > > Distribution of MPLS Traffic Engineering (TE) LSP State using BGP > draft-dong-idr-te-lsp-distribution-04 > > https://datatracker.ietf.org/doc/draft-dong-idr-te-lsp-distribution/ > > WG 2 week calls begins 1/9/14 and ends 1/22/14 I support this. It's a reasonable extension of the LS-distribution draft. Development of this also lends support to the need for the IANA registry for LS-distribution. (Note to authors, please update your IANA considerations to show that you want values 5 and 6 to be allocated from IANA.) -- Jeff From sairay@cisco.com Tue Jan 21 12:46:23 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 869BE1A0349 for ; Tue, 21 Jan 2014 12:46:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.035 X-Spam-Level: X-Spam-Status: No, score=-15.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xs2HLSU3LKiG for ; Tue, 21 Jan 2014 12:46:21 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2D64D1A0348 for ; Tue, 21 Jan 2014 12:46:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7252; q=dns/txt; s=iport; t=1390337181; x=1391546781; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=on+G3YFN0B6zMF11CsVUDoQZfz5AS/+Jc0cy73Im3Sk=; b=B6ZepfR7OV7BoC/64OiyHRkCqNpoT82/7RmfOxyEPPT5L/+rnLeK0yKW s1/PxwfcnhjmapsK6jgRYko3tz9zqwtLMbY/WvDqo2GTmjhbEUH8Oq70M uJYugV+0LCf+wfTa3ClugyZlfcaE8IrEkB+mfBdPUwJ1biim7ydcNMe4P k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAFjb3lKtJV2b/2dsb2JhbABZgkdEOFa7coEWFnSCJQEBAQQdEFwCAQgOAwQBAQsdBzIUCQgBAQQBEgiHfQ3DAxMEjk4tCgGDJIEUBKo6gy2CKg X-IronPort-AV: E=Sophos;i="4.95,697,1384300800"; d="scan'208,217";a="298773640" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 21 Jan 2014 20:46:20 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0LKkKjU005590 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jan 2014 20:46:20 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.24]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Tue, 21 Jan 2014 14:46:19 -0600 From: "Saikat Ray (sairay)" To: Susan Hares , idr wg Thread-Topic: [Idr] WG Adoption call for draft-dong-idr-te-lsp-distribution Thread-Index: Ac8NUGUcV9wGRG4eS5qk8rMSu5JkuQJmWivQ Date: Tue, 21 Jan 2014 20:46:19 +0000 Message-ID: <8ED5B0B0F5B4854A912480C1521F973A11AF5D0A@xmb-rcd-x13.cisco.com> References: <035201cf0d50$65cbbef0$31633cd0$@ndzh.com> In-Reply-To: <035201cf0d50$65cbbef0$31633cd0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.166.25] Content-Type: multipart/alternative; boundary="_000_8ED5B0B0F5B4854A912480C1521F973A11AF5D0Axmbrcdx13ciscoc_" MIME-Version: 1.0 Subject: Re: [Idr] WG Adoption call for draft-dong-idr-te-lsp-distribution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 20:46:23 -0000 --_000_8ED5B0B0F5B4854A912480C1521F973A11AF5D0Axmbrcdx13ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1. From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Thursday, January 09, 2014 7:35 AM To: idr wg Cc: draft-dong-idr-te-lsp-distribution@tools.ietf.org Subject: [Idr] WG Adoption call for draft-dong-idr-te-lsp-distribution IDR WG: This is to give a 2 week Call for adoption of: Distribution of MPLS Traffic Engineering (TE) LSP State using BGP draft-dong-idr-te-lsp-distribution-04 https://datatracker.ietf.org/doc/draft-dong-idr-te-lsp-distribution/ WG 2 week calls begins 1/9/14 and ends 1/22/14 Technical description: This document describes a mechanism to collect the Traffic Engineering (TE)= LSP information using BGP. Such information can be used by external compo= nents for path re-optimization, service placement and network visualization= . Sue and John IDR co-chairs --_000_8ED5B0B0F5B4854A912480C1521F973A11AF5D0Axmbrcdx13ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1.=

 <= /p>

From: Idr [mai= lto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Thursday, January 09, 2014 7:35 AM
To: idr wg
Cc: draft-dong-idr-te-lsp-distribution@tools.ietf.org
Subject: [Idr] WG Adoption call for draft-dong-idr-te-lsp-distributi= on

 

IDR WG:

 

This is to give a 2 week Call for adoptio= n of:

 

Distribution= of MPLS Traffic Engineering (TE) LSP State using BGP

draft-dong-idr-te-lsp-distribution-04

 

https://datatracker.ietf.org/doc/dr= aft-dong-idr-te-lsp-distribution/

 

WG 2 week calls begins 1/9/14 and ends 1/= 22/14

 

Technical= description:

This documen= t describes a mechanism to collect the Traffic Engineering (TE) LSP informa= tion using BGP.  Such information can be used by external components for path re-optimization, service placement and network visuali= zation.

 <= /o:p>

 <= /o:p>

Sue and John

IDR co-chair= s

 <= /o:p>

--_000_8ED5B0B0F5B4854A912480C1521F973A11AF5D0Axmbrcdx13ciscoc_-- From pierre.francois@imdea.org Tue Jan 21 12:49:44 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDAE31A01D1 for ; Tue, 21 Jan 2014 12:49:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgvF1uefTzsE for ; Tue, 21 Jan 2014 12:49:40 -0800 (PST) Received: from estafeta21.imdea.org (maquina46.madrimasd.org [193.145.15.46]) by ietfa.amsl.com (Postfix) with ESMTP id 07AF81A01A6 for ; Tue, 21 Jan 2014 12:49:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by estafeta21.imdea.org (imdea mail daemon) with ESMTP id 0BB351BFE1E; Tue, 21 Jan 2014 21:49:33 +0100 (CET) X-Virus-Scanned: by antispam-antivirus system at imdea.org Received: from estafeta21.imdea.org ([127.0.0.1]) by localhost (estafeta21.imdea.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USKuHgM1WFYj; Tue, 21 Jan 2014 21:49:32 +0100 (CET) Received: from [10.95.21.72] (23.Red-176-83-35.dynamicIP.rima-tde.net [176.83.35.23]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: pierre.francois) by estafeta21.imdea.org (imdea mail daemon) with ESMTPSA id 30D661BFE1D; Tue, 21 Jan 2014 21:49:32 +0100 (CET) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-58F5AA6D-CFDF-489A-BA13-058C8B4F7A6B Content-Transfer-Encoding: 7bit Message-Id: <7983028A-9398-45DE-B42E-70A60AFF1028@imdea.org> X-Mailer: iPhone Mail (11B554a) From: Pierre Francois Date: Tue, 21 Jan 2014 21:49:38 +0100 To: "Keyur Patel (keyupate)" Cc: idr wg , Susan Hares , "draft-dong-idr-te-lsp-distribution@tools.ietf.org" Subject: Re: [Idr] WG Adoption call for draft-dong-idr-te-lsp-distribution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 20:49:45 -0000 --Apple-Mail-58F5AA6D-CFDF-489A-BA13-058C8B4F7A6B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Support. Pierre. > On Jan 21, 2014, at 6:58 PM, "Keyur Patel (keyupate)" = wrote: >=20 > Support. >=20 > Regards, > Keyur >=20 > From: Susan Hares > Date: Thu, 9 Jan 2014 10:35:16 -0500 > To: idr wg > Cc: > Subject: [Idr] WG Adoption call for draft-dong-idr-te-lsp-distribution >=20 > IDR WG: > =20 > This is to give a 2 week Call for adoption of: > =20 > Distribution of MPLS Traffic Engineering (TE) LSP State using BGP > draft-dong-idr-te-lsp-distribution-04 > =20 > https://datatracker.ietf.org/doc/draft-dong-idr-te-lsp-distribution/ > =20 > WG 2 week calls begins 1/9/14 and ends 1/22/14 > =20 > Technical description: > This document describes a mechanism to collect the Traffic Engineering (TE= ) LSP information using BGP. Such information can be used by external compo= nents for path re-optimization, service placement and network visualization.= > =20 > =20 > Sue and John > IDR co-chairs > =20 > _______________________________________________ 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 --Apple-Mail-58F5AA6D-CFDF-489A-BA13-058C8B4F7A6B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Support.

Pierre.


On Jan 21, 2014, at 6:58 PM, "Keyur Patel (keyupate)" <keyupate@cisco.com> wrote:

Support.

Regards,
Keyur

From: Susan Hares <shares@ndzh.com>
Date: Thu, 9 Jan 2014 10:35:16 -0500
To: idr wg <idr@ietf.org>
Cc: <draft-dong-idr-te-lsp-distribution@tools.ietf.org>
Subject: [Idr] WG Adoption call for draft-dong-idr-te-lsp-distribution

IDR WG:

 

This is to give a 2 week Call for adoption of:

 

Distribution of MPLS Traffic Engineering (TE) LSP State using BGP

draft-dong-idr-te-lsp-distribution-04

 

https://datatracker.ietf.org/doc/draft-dong-idr-te-lsp-distribution/

 

WG 2 week calls begins 1/9/14 and ends 1/22/14

 

Technical description:

This document describes a mechanism to collect the Traffic Engineering (TE) LSP information using BGP.  Such information can be used by external components for path re-optimization, service placement and network visualization.

 

 

Sue and John

IDR co-chairs

 

_______________________________________________ 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
--Apple-Mail-58F5AA6D-CFDF-489A-BA13-058C8B4F7A6B-- From jhaas@slice.pfrc.org Tue Jan 21 14:35:20 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC8651A033F for ; Tue, 21 Jan 2014 14:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PznzwWw14Si for ; Tue, 21 Jan 2014 14:35:19 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7EEF51A02D2 for ; Tue, 21 Jan 2014 14:35:19 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 440A2C17E; Tue, 21 Jan 2014 17:35:19 -0500 (EST) Date: Tue, 21 Jan 2014 17:35:19 -0500 From: Jeffrey Haas To: Susan Hares Message-ID: <20140121223519.GJ4366@pfrc> References: <026801cf0d04$af4998a0$0ddcc9e0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <026801cf0d04$af4998a0$0ddcc9e0$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: idr wg , "'John G. Scudder'" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 22:35:21 -0000 On Thu, Jan 09, 2014 at 01:33:18AM -0500, Susan Hares wrote: > This is a 2 week WG LC for IPR on the following draft: > > Enhanced Route Refresh Capability for BGP-4 > draft-ietf-idr-bgp-enhanced-route-refresh-05.txt > > The 2 week WG LC starts on 1/9/14 and ends on 1/22/14. > > The questions are as follows: > > 1) Do the co-authors or any WG participant know of any IPR on this draft? I do not. > 2) Do you support the draft-ietf-idr-bgp-enhanced-route-refresh-05.txt I do. (Even though my last name has continued to be mis-capitalized in the last several revs. :-) -- Jeff From balaji_pv@hotmail.com Tue Jan 21 22:05:33 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C86D1A01B8 for ; Tue, 21 Jan 2014 22:05:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWwzq3YYOUYu for ; Tue, 21 Jan 2014 22:05:29 -0800 (PST) Received: from col0-omc1-s3.col0.hotmail.com (col0-omc1-s3.col0.hotmail.com [65.55.34.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2FD1A01C8 for ; Tue, 21 Jan 2014 22:05:29 -0800 (PST) Received: from COL127-W40 ([65.55.34.9]) by col0-omc1-s3.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Jan 2014 22:05:29 -0800 X-TMN: [eqINCczphgHs55nTgQ7GT9qnixxX9ihA] X-Originating-Email: [balaji_pv@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_c67bf0e2-6b87-4d7c-8b75-118ca778b18c_" From: Balaji Pitta venkatachalapathy To: Susan Hares , idr wg Date: Tue, 21 Jan 2014 22:05:29 -0800 Importance: Normal In-Reply-To: References: <026801cf0d04$af4998a0$0ddcc9e0$@ndzh.com>, MIME-Version: 1.0 X-OriginalArrivalTime: 22 Jan 2014 06:05:29.0143 (UTC) FILETIME=[F3692C70:01CF1737] Cc: "'John G. Scudder'" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 06:05:33 -0000 --_c67bf0e2-6b87-4d7c-8b75-118ca778b18c_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As co-author=2C I am not aware of any IPR related to the draft. Thanks Balaji =0A= =0A= =0A= =0A= From: Susan Hares =0A= Date: Wednesday=2C January 8=2C 2014 10:33 PM =0A= To: idr wg =0A= Cc: "'John G. Scudder'" =0A= Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Correcting the header. =0A= Sue =0A= =0A= =0A= =0A= From: Susan Hares [mailto:shares@ndzh.com]=0A= =0A= Sent: Thursday=2C January 09=2C 2014 1:25 AM =0A= To: idr wg (idr@ietf.org) =0A= Cc: 'John G. Scudder'=3B John G. Scudder (jgs@juniper.net) =0A= Subject: WG LC for =0A= =0A= =0A= =0A= This is a 2 week WG LC for IPR on the following draft:=0A= =0A= =0A= Enhanced Route Refresh Capability for BGP-4=0A= draft-ietf-idr-bgp-enhanced-route-refresh-05.txt=0A= =0A= The 2 week WG LC starts on 1/9/14 and ends on 1/22/14.=0A= =0A= The questions are as follows:=0A= =0A= 1) =0A= Do the co-authors or any WG participant know of any IPR on this draft?=0A= =0A= 2) =0A= Do you support the draft-ietf-idr-bgp-enhanced-route-refresh-05.txt=0A= For publishing as an RFC?=0A= =0A= Sample answer:=0A= 1) =0A= IPR: I do/I do not know of IPR for this draft =0A= 2) =0A= RFC: Support=0A= =0A= =0A= =0A= Comments are always welcome.=0A= =0A= =0A= Sue and John=0A= WG chairs=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= _______________________________________________=0A= Idr mailing list=0A= Idr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/idr = --_c67bf0e2-6b87-4d7c-8b75-118ca778b18c_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
As co-author=2C I am not aw= are of any IPR related to the draft.

Thanks
Balaji

= =0A=
=0A= =0A=
=0A= From: Susan Hares <=3Bshares@ndzh.com>=3B
=0A= Date: Wednesday=2C January 8=2C = 2014 10:33 PM
=0A= To: idr wg <=3Bidr@ietf.org>=3B
=0A= Cc: "'John G. Scudder'" <=3Bjgs@bgp.nu>=3B
=0A= Subject: Re: [Idr] WG LC for dra= ft-ietf-idr-bgp-enhanced-route-refresh
=0A=
=0A=

=0A=
=0A=
=0A= =0A= =0A=
=0A=
=0A=

Correcting the h= eader.

=0A=

Sue

= =0A=

 =3B<= /p>=0A=

=0A=
=0A=

From: Susan Hares [mailto:shares@ndzh.com]=0A=
=0A= Sent: Thursday=2C January 09=2C 2014 1:25 AM
=0A= To: idr wg (idr@ietf.org)
=0A= Cc: 'John G. Scudder'=3B John G. Scudder (jgs@juniper.net)
=0A= Subject: WG LC for

=0A=
=0A=
=0A=

 =3B

=0A=

This is a 2 week WG LC for IPR on the following draft:=0A=

=0A=

 =3B

=0A=

Enhanced Route Refresh Capabil= ity for BGP-4

=0A=

draft-ietf-idr-bgp-enhanced-route-refresh-05.txt

=0A=

 =3B

=0A=

The 2 week WG LC starts on 1/9/14 and ends on 1/22/14.<= /p>=0A=

 =3B

=0A=

The questions are as follows:

=0A=

 =3B

=0A=

1) =3B=0A= Do the co-authors or any WG participant know of any IPR on this dra= ft?=0A=

=0A=

2) =3B=0A= Do you support the draft-ietf-idr-bgp-enhanced-route-refresh-05.txt=

=0A=

For publishing as an RFC?

=0A=

 =3B

=0A=

Sample answer:

=0A=

1) =3B=0A= IPR: I do/I do not know of IPR for this draft  =3B

= =0A=

2) =3B=0A= RFC: Support=0A=

=0A=

 =3B

=0A=

 =3B

=0A=

Comments are always welcome.=0A=

=0A=

 =3B

=0A=

Sue and John

=0A=

WG chairs=0A=

=0A=

 =3B

=0A=

 =3B

=0A=

 =3B

=0A=
=0A=
=0A=
=0A= =0A= =0A= =0A=
_______________________________________________=0A= Idr mailing list=0A= Idr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/idr
= --_c67bf0e2-6b87-4d7c-8b75-118ca778b18c_-- From bruno.decraene@orange.com Wed Jan 22 00:21:06 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFA191A025F for ; Wed, 22 Jan 2014 00:21:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZhMyEl1TW5q for ; Wed, 22 Jan 2014 00:21:04 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id DCA001A0231 for ; Wed, 22 Jan 2014 00:21:03 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 9CE162AC6E6; Wed, 22 Jan 2014 09:21:02 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 7FC45C804F; Wed, 22 Jan 2014 09:21:02 +0100 (CET) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Wed, 22 Jan 2014 09:21:02 +0100 From: To: Susan Hares , "'John G. Scudder'" Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: Ac8NBKMrKHMolEg8TF26AxOKep0T6AKRfuYQ Date: Wed, 22 Jan 2014 08:21:01 +0000 Message-ID: <30814_1390378862_52DF7F6E_30814_14870_1_53C29892C857584299CBF5D05346208A070DD70D@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <026801cf0d04$af4998a0$0ddcc9e0$@ndzh.com> In-Reply-To: <026801cf0d04$af4998a0$0ddcc9e0$@ndzh.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A070DD70DPEXCVZYM11corpo_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.21.133016 Cc: idr wg Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 08:21:06 -0000 --_000_53C29892C857584299CBF5D05346208A070DD70DPEXCVZYM11corpo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > Do you support the draft-ietf-idr-bgp-enhanced-route-refresh-05.txt For p= ublishing as an RFC? RFC: Support Thanks, Bruno From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Thursday, January 09, 2014 7:33 AM To: idr wg Cc: 'John G. Scudder' Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Correcting the header. Sue From: Susan Hares [mailto:shares@ndzh.com] Sent: Thursday, January 09, 2014 1:25 AM To: idr wg (idr@ietf.org) Cc: 'John G. Scudder'; John G. Scudder (jgs@juniper.net) Subject: WG LC for This is a 2 week WG LC for IPR on the following draft: Enhanced Route Refresh Capability for BGP-4 draft-ietf-idr-bgp-enhanced-route-refresh-05.txt The 2 week WG LC starts on 1/9/14 and ends on 1/22/14. The questions are as follows: 1) Do the co-authors or any WG participant know of any IPR on this draft? 2) Do you support the draft-ietf-idr-bgp-enhanced-route-refresh-05.txt For publishing as an RFC? Sample answer: 1) IPR: I do/I do not know of IPR for this draft 2) RFC: Support Comments are always welcome. Sue and John WG chairs ___________________________________________________________________________= ______________________________________________ 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, 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 authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A070DD70DPEXCVZYM11corpo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> Do you support the draft-ietf-idr-bgp-= enhanced-route-refresh-05.txt For publishing as an RFC?

 

RFC: Support

 

Thanks,

Bruno

 

From: Idr [mai= lto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Thursday, January 09, 2014 7:33 AM
To: idr wg
Cc: 'John G. Scudder'
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refre= sh

 

Correct= ing the header.

Sue

&n= bsp;

From: Susan Hares [mailt= o:shares@ndzh.com]
Sent: Thursday, January 09, 2014 1:25 AM
To: idr wg (idr@ietf.org)
Cc: 'John G. Scudder'; John G. Scudder (jgs@juniper.net)
Subject: WG LC for

 

This is a 2 week WG LC for IPR on the follo= wing draft:

 

Enhanced Route= Refresh Capability for BGP-4

draft-ietf-idr-bgp-enhanced-route-refresh-0= 5.txt

 

The 2 week WG LC starts on 1/9/14 and ends = on 1/22/14.

 

The questions are as follows:

 

1)  Do the co-authors or any WG partici= pant know of any IPR on this draft?

2)  Do you support the draft-ietf-idr-b= gp-enhanced-route-refresh-05.txt

For publishing as an RFC?=

 

Sample answer:

1)  IPR: I do/I do not know of IPR for = this draft  

2)  RFC: Support

 

 

Comments are always welcome.

 

Sue and John

WG chairs

 

 

 

______________________________________________________________________=
___________________________________________________

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,
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 authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A070DD70DPEXCVZYM11corpo_-- From mach.chen@huawei.com Wed Jan 22 00:50:10 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2CF11A029D for ; Wed, 22 Jan 2014 00:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1SnBPcxNzDU for ; Wed, 22 Jan 2014 00:50:07 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5801A0248 for ; Wed, 22 Jan 2014 00:50:06 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAH30049; Wed, 22 Jan 2014 08:50:05 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 22 Jan 2014 08:48:59 +0000 Received: from SZXEMA404-HUB.china.huawei.com (10.82.72.36) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 22 Jan 2014 08:50:00 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.206]) by SZXEMA404-HUB.china.huawei.com ([10.82.72.36]) with mapi id 14.03.0158.001; Wed, 22 Jan 2014 16:49:56 +0800 From: Mach Chen To: Susan Hares , idr wg Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: Ac8NBKMrKHMolEg8TF26AxOKep0T6AKSis9g Date: Wed, 22 Jan 2014 08:49:55 +0000 Message-ID: References: <026801cf0d04$af4998a0$0ddcc9e0$@ndzh.com> In-Reply-To: <026801cf0d04$af4998a0$0ddcc9e0$@ndzh.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25D954C2ASZXEMA510MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "'John G. Scudder'" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 08:50:10 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25D954C2ASZXEMA510MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Do you support the draft-ietf-idr-bgp-enhanced-route-refresh-05.txt For publishing as an RFC? Yes, support. Best regards, Mach From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Thursday, January 09, 2014 2:33 PM To: idr wg Cc: 'John G. Scudder' Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Correcting the header. Sue From: Susan Hares [mailto:shares@ndzh.com] Sent: Thursday, January 09, 2014 1:25 AM To: idr wg (idr@ietf.org) Cc: 'John G. Scudder'; John G. Scudder (jgs@juniper.net) Subject: WG LC for This is a 2 week WG LC for IPR on the following draft: Enhanced Route Refresh Capability for BGP-4 draft-ietf-idr-bgp-enhanced-route-refresh-05.txt The 2 week WG LC starts on 1/9/14 and ends on 1/22/14. The questions are as follows: 1) Do the co-authors or any WG participant know of any IPR on this draft? 2) Do you support the draft-ietf-idr-bgp-enhanced-route-refresh-05.txt For publishing as an RFC? Sample answer: 1) IPR: I do/I do not know of IPR for this draft 2) RFC: Support Comments are always welcome. Sue and John WG chairs --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25D954C2ASZXEMA510MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

=  

=  

From: Idr [mailto:idr-bounces@ietf.org] On B= ehalf Of Susan Hares
Sent: Thursday, January 09, = 2014 2:33 PM
To: idr wg
Cc: 'John G. Scudder'
Subject: Re: [Idr] WG LC for= draft-ietf-idr-bgp-enhanced-route-refresh

 

= Correcting th= e header.

= Sue

=  

From: Susan Hares [mailto:shares@ndzh.com= ]
Sent: Thursday, January 09, = 2014 1:25 AM
To: idr wg (idr@ietf.org)
Cc: 'John G. Scudder'; John = G. Scudder (jgs@juniper.net)
Subject: WG LC for

 

This = is a 2 week WG LC for IPR on the following draft:

 

Enhanced Route Refresh Capability for BGP-4<= /o:p>

draft= -ietf-idr-bgp-enhanced-route-refresh-05.txt

=  

The 2= week WG LC starts on 1/9/14 and ends on 1/22/14.<= /p>

=  

The q= uestions are as follows:

=  

1)  Do the co-authors or any WG participant know of any IPR on= this draft?

2)  Do you support the draft-ietf-idr-bgp-enhanced-route-refre= sh-05.txt

=  

Sampl= e answer:

1)  IPR: I do/I do not know of IPR for this draft  <= /o:p>

2)  RFC: Support

=  

=  

Comme= nts are always welcome.

=  

Sue a= nd John

WG ch= airs

 

 

 

--_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE25D954C2ASZXEMA510MBXchi_-- From kotikalapudi.sriram@nist.gov Wed Jan 22 09:19:56 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3061A0160 for ; Wed, 22 Jan 2014 09:19:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S53ROQPekMRx for ; Wed, 22 Jan 2014 09:19:52 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0156.outbound.protection.outlook.com [207.46.163.156]) by ietfa.amsl.com (Postfix) with ESMTP id 515251A011B for ; Wed, 22 Jan 2014 09:19:52 -0800 (PST) Received: from BLUPR09MB053.namprd09.prod.outlook.com (10.255.211.146) by BLUPR09MB053.namprd09.prod.outlook.com (10.255.211.146) with Microsoft SMTP Server (TLS) id 15.0.859.15; Wed, 22 Jan 2014 17:19:50 +0000 Received: from BLUPR09MB053.namprd09.prod.outlook.com ([169.254.14.198]) by BLUPR09MB053.namprd09.prod.outlook.com ([169.254.14.198]) with mapi id 15.00.0859.013; Wed, 22 Jan 2014 17:19:50 +0000 From: "Sriram, Kotikalapudi" To: "idr@ietf.org" , "\"Keyur Patel (keyupate)\"" Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPF5KdRBAmgx68fEWwXG4FsR9w+w== Date: Wed, 22 Jan 2014 17:19:49 +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: [129.6.222.248] x-forefront-prvs: 00997889E7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(189002)(199002)(31966008)(76576001)(63696002)(87266001)(77096001)(74502001)(47446002)(74662001)(79102001)(81816001)(81542001)(69226001)(76796001)(76786001)(77982001)(54316002)(59766001)(56776001)(4396001)(65816001)(83072002)(49866001)(85852003)(47736001)(74876001)(80022001)(47976001)(53806001)(50986001)(51856001)(54356001)(33646001)(83322001)(74706001)(86362001)(46102001)(66066001)(85306002)(56816005)(2656002)(87936001)(81342001)(76482001)(93136001)(74366001)(92566001)(81686001)(93516002)(74316001)(90146001)(80976001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR09MB053; H:BLUPR09MB053.namprd09.prod.outlook.com; CLIP:129.6.222.248; FPR:; MLV:nspm; InfoNoRecordsMX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 17:19:56 -0000 I support the publication of this ID as an RFC.=0A= I have one comment:=0A= =0A= Quoting from Section 4:=0A= "When a route entry in the "ADJ-RIB-Out" changes, only=0A= the modified route entry needs to be advertised."=0A= =0A= I think the above statement is true in general, regardless of the route ref= resh.=0A= Just wondering if it should be clearer in the document what the operational= =0A= implication is in the context of enhanced route refresh.=0A= If changes happen during the ERR (between BoRR and EoRR),=0A= do you advertise each change right away, or do you finish sending=0A= the Adj-RIB-Out (whatever you had at the start of route refresh)=0A= and then advertise the changes (just prior to sending the EoRR)?=0A= =0A= Sriram=0A= =0A= =0A= =0A= =0A= From jakob.heitz@ericsson.com Wed Jan 22 12:49:15 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B071A0454 for ; Wed, 22 Jan 2014 12:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-RuhTgJIh96 for ; Wed, 22 Jan 2014 12:49:12 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 840AC1A048C for ; Wed, 22 Jan 2014 12:49:11 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-7f-52e02ec33632 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id FA.2E.12743.3CE20E25; Wed, 22 Jan 2014 21:49:07 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0387.000; Wed, 22 Jan 2014 15:49:10 -0500 From: Jakob Heitz To: "Sriram, Kotikalapudi" , "idr@ietf.org" , "\"Keyur Patel (keyupate)\"" Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPF5KdKHMolEg8TF26AxOKep0T6JqRMOhA Date: Wed, 22 Jan 2014 20:49:10 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F54ED5@eusaamb109.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyuXRPiO5hvQdBBrdeWFq8uv2MyaJx63k2 i8l77rA6MHtM+b2R1WPJkp9MHtdO/mUNYI7isklJzcksSy3St0vgyvj05RxzwUahit/3tjA3 ML7l62Lk5JAQMJE4cewMK4QtJnHh3nq2LkYuDiGBI4wSL9/+ZodwljNKnP32gw2kik1AR+Lb 9S5mkISIQC+jxN3ny8HahQXcJO62fGYCsUUE3CVafkxihrCNJE42HgCLswioSrQ9ngUW5xXw lXh3fRcjxIYmRolzE04CJTg4OAXCJA7fqgCpYQQ66fupNWC9zALiEreezGeCOFVAYsme88wQ tqjEy8f/oF5Qkpi09BwrRL2OxILdn9ggbG2JZQtfQ+0VlDg58wnLBEbRWUjGzkLSMgtJyywk LQsYWVYxcpQWp5blphsZbGIERskxCTbdHYx7XloeYpTmYFES5/3y1jlISCA9sSQ1OzW1ILUo vqg0J7X4ECMTB6dUA+O6VacPceteuqF8x7ScyfoHyxJjBm+L2OMXX0zkZrYVS7yxOzbo75yi jqzPy6u9lQ9d8l1hcaztts9pgZZPj6TarrTvn9TZ5HNH4JNAq/2a5IV5j/kFTFn8G4WTE7of 7Ug6fVJ07xOfh8mfClNuVEiH2Cx6POe81LqzIfc2fRRQj0v53bm5KEGJpTgj0VCLuag4EQCT mYSHYAIAAA== Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 20:49:15 -0000 My interpretation: It means the implementation does not have to do a snapshot. If a route changes during the refresh (after BoRR, before EoRR), it is an implementation decision whether to advertise just the latest versi= on of the route or also the older version. Suppose a speaker sends BoRR, then sends an update for a particular route, then that route changes, then the speaker sends updates for other routes, then it sends EoRR. The final change to the particular route may be sent before or after the EoRR. In another scenario, a speaker sends BoRR and starts advertising routes. Then a particular route that has not yet been advertised as part of the ref= resh changes. It is an implementation decision whether to just advertise the latest versi= on of the route or the original version. The latest version must be advertised= either before or after the EoRR. At least one version of the route must be adverti= sed before the EoRR. What it means is that an implementation is free to consider an incoming route change to have happened before, during or after the refresh operation= . The intent in the draft is to allow the receiver to delete stale routes upon receipt of the EoRR. Thanks, Jakob. -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Sriram, Kotikalapudi Sent: Wednesday, January 22, 2014 9:20 AM To: idr@ietf.org; "Keyur Patel (keyupate)" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh I support the publication of this ID as an RFC. I have one comment: Quoting from Section 4: "When a route entry in the "ADJ-RIB-Out" changes, only the modified route entry needs to be advertised." I think the above statement is true in general, regardless of the route ref= resh. Just wondering if it should be clearer in the document what the operational= implication is in the context of enhanced route refresh. If changes happen during the ERR (between BoRR and EoRR), do you advertise = each change right away, or do you finish sending the Adj-RIB-Out (whatever = you had at the start of route refresh) and then advertise the changes (just= prior to sending the EoRR)? Sriram =20 =20 _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From keyupate@cisco.com Wed Jan 22 16:19:05 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF2B1A0136 for ; Wed, 22 Jan 2014 16:19:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2D8ZfPYHH2YP for ; Wed, 22 Jan 2014 16:19:02 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 690E81A0116 for ; Wed, 22 Jan 2014 16:19:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2494; q=dns/txt; s=iport; t=1390436342; x=1391645942; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=RWKIJr/EKUmHARlMQhHcqgpGc49jSnBO2qyoxccKc5c=; b=P6Oow1+LbmxJPxjaHtW230db+lHMtvPaT4ASIL9CA89FBwLyzDQK9zgR fmLTgUiNFft7GR66GvJf9PUBVksZ/ql+/0ba2+Y2UlkPzZufzDVHyscDT H0McYwmeQ7a/VAT4O7qJ2vclx1D3i4GWKzgTSxljacgTCZKyPUVCre/wv g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FALBf4FKtJV2a/2dsb2JhbABbgww4VrtfgRQWdIIlAQEBBAEBATc0FwYBCBEEAQEfCS4LFAkIAgQBEogFDcQoEwSPAwaEMgSYIpIYgy2CKg X-IronPort-AV: E=Sophos;i="4.95,703,1384300800"; d="scan'208";a="299051157" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 23 Jan 2014 00:19:01 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0N0J1o2004352 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Jan 2014 00:19:01 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.228]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Wed, 22 Jan 2014 18:19:01 -0600 From: "Keyur Patel (keyupate)" To: Jakob Heitz , "Sriram, Kotikalapudi" , "idr@ietf.org" Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPF9C2nSg2v8KK+0+W7r0WcIWGPQ== Date: Thu, 23 Jan 2014 00:19:00 +0000 Message-ID: In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F54ED5@eusaamb109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [128.107.163.49] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 00:19:05 -0000 +1. Regards, Keyur On 1/22/14 12:49 PM, "Jakob Heitz" wrote: >My interpretation: > >It means the implementation does not have to do a snapshot. >If a route changes during the refresh (after BoRR, before EoRR), >it is an implementation decision whether to advertise just the latest >version of the route >or also the older version. > >Suppose a speaker sends BoRR, then sends an update for a particular route, >then that route changes, then the speaker sends updates for other routes, >then it sends EoRR. The final change to the particular route may be sent >before or after the EoRR. > >In another scenario, a speaker sends BoRR and starts advertising routes. >Then a particular route that has not yet been advertised as part of the >refresh changes. >It is an implementation decision whether to just advertise the latest >version >of the route or the original version. The latest version must be >advertised either >before or after the EoRR. At least one version of the route must be >advertised >before the EoRR. > >What it means is that an implementation is free to consider an incoming >route change to have happened before, during or after the refresh >operation. > >The intent in the draft is to allow the receiver to delete stale routes >upon receipt of the EoRR. > >Thanks, >Jakob. > >-----Original Message----- >From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Sriram, Kotikalapudi >Sent: Wednesday, January 22, 2014 9:20 AM >To: idr@ietf.org; "Keyur Patel (keyupate)" >Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh > >I support the publication of this ID as an RFC. >I have one comment: > >Quoting from Section 4: >"When a route entry in the "ADJ-RIB-Out" changes, only > the modified route entry needs to be advertised." > >I think the above statement is true in general, regardless of the route >refresh. >Just wondering if it should be clearer in the document what the >operational implication is in the context of enhanced route refresh. >If changes happen during the ERR (between BoRR and EoRR), do you >advertise each change right away, or do you finish sending the >Adj-RIB-Out (whatever you had at the start of route refresh) and then >advertise the changes (just prior to sending the EoRR)? > >Sriram > =20 >=20 > > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From jie.dong@huawei.com Thu Jan 23 00:22:45 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E57C51A0236 for ; Thu, 23 Jan 2014 00:22:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yh7wFpei5cUA for ; Thu, 23 Jan 2014 00:22:43 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 214EC1A0075 for ; Thu, 23 Jan 2014 00:22:41 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCV46855; Thu, 23 Jan 2014 08:22:40 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 23 Jan 2014 08:22:22 +0000 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 23 Jan 2014 08:22:37 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.51]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Thu, 23 Jan 2014 16:22:30 +0800 From: "Dongjie (Jimmy)" To: Susan Hares , idr wg Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: Ac8NBKMrKHMolEg8TF26AxOKep0T6ALD1mEA Date: Thu, 23 Jan 2014 08:22:30 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927335C2EF8@nkgeml512-mbx.china.huawei.com> References: <026801cf0d04$af4998a0$0ddcc9e0$@ndzh.com> In-Reply-To: <026801cf0d04$af4998a0$0ddcc9e0$@ndzh.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.192.135] Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C927335C2EF8nkgeml512mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "'John G. Scudder'" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 08:22:46 -0000 --_000_76CD132C3ADEF848BD84D028D243C927335C2EF8nkgeml512mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 2) Do you support the draft-ietf-idr-bgp-enhanced-route-refresh-05.txt For = publishing as an RFC? RFC: Support. Regards, Jie From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Thursday, January 09, 2014 9:33 AM To: idr wg Cc: 'John G. Scudder' Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Correcting the header. Sue From: Susan Hares [mailto:shares@ndzh.com] Sent: Thursday, January 09, 2014 1:25 AM To: idr wg (idr@ietf.org) Cc: 'John G. Scudder'; John G. Scudder (jgs@juniper.net) Subject: WG LC for This is a 2 week WG LC for IPR on the following draft: Enhanced Route Refresh Capability for BGP-4 draft-ietf-idr-bgp-enhanced-route-refresh-05.txt The 2 week WG LC starts on 1/9/14 and ends on 1/22/14. The questions are as follows: 1) Do the co-authors or any WG participant know of any IPR on this draft? 2) Do you support the draft-ietf-idr-bgp-enhanced-route-refresh-05.txt For publishing as an RFC? Sample answer: 1) IPR: I do/I do not know of IPR for this draft 2) RFC: Support Comments are always welcome. Sue and John WG chairs --_000_76CD132C3ADEF848BD84D028D243C927335C2EF8nkgeml512mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

2) Do you support the draft-ietf-idr-bgp-enhanced-route-refresh-0= 5.txt For publishing as an RFC?

 

RFC: Support.

 

Regards= ,

Jie

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Thursday, January 09, 2014 9:33 AM
To: idr wg
Cc: 'John G. Scudder'
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refre= sh

 

Correct= ing the header.

Sue

&n= bsp;

From: Susan Hares [mailt= o:shares@ndzh.com]
Sent: Thursday, January 09, 2014 1:25 AM
To: idr wg (idr@ietf.org)
Cc: 'John G. Scudder'; John G. Scudder (jgs@juniper.net)
Subject: WG LC for

 

This is a 2 week WG LC for IPR on the follo= wing draft:

 

Enhanced Route= Refresh Capability for BGP-4

draft-ietf-idr-bgp-enhanced-route-refresh-0= 5.txt

 

The 2 week WG LC starts on 1/9/14 and ends = on 1/22/14.

 

The questions are as follows:

 

1)  Do the co-authors or any WG partici= pant know of any IPR on this draft?

2)  Do you support the draft-ietf-idr-b= gp-enhanced-route-refresh-05.txt

For publishing as an RFC?=

 

Sample answer:

1)  IPR: I do/I do not know of IPR for = this draft  

2)  RFC: Support

 

 

Comments are always welcome.

 

Sue and John

WG chairs

 

 

 

--_000_76CD132C3ADEF848BD84D028D243C927335C2EF8nkgeml512mbxchi_-- From kotikalapudi.sriram@nist.gov Thu Jan 23 08:11:07 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 271971A000A for ; Thu, 23 Jan 2014 08:11:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9I7BOPnjehVn for ; Thu, 23 Jan 2014 08:11:05 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0155.outbound.protection.outlook.com [207.46.163.155]) by ietfa.amsl.com (Postfix) with ESMTP id 5871B1A0006 for ; Thu, 23 Jan 2014 08:11:05 -0800 (PST) Received: from BLUPR09MB053.namprd09.prod.outlook.com (10.255.211.146) by BLUPR09MB053.namprd09.prod.outlook.com (10.255.211.146) with Microsoft SMTP Server (TLS) id 15.0.859.15; Thu, 23 Jan 2014 16:11:02 +0000 Received: from BLUPR09MB053.namprd09.prod.outlook.com ([169.254.14.198]) by BLUPR09MB053.namprd09.prod.outlook.com ([169.254.14.198]) with mapi id 15.00.0859.013; Thu, 23 Jan 2014 16:11:02 +0000 From: "Sriram, Kotikalapudi" To: Jakob Heitz , "idr@ietf.org" , "\"Keyur Patel (keyupate)\"" Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPF5KdRBAmgx68fEWwXG4FsR9w+5qRN6cAgAFAj+A= Date: Thu, 23 Jan 2014 16:11:02 +0000 Message-ID: <10eca092172d443380eccf2e8548f2a9@BLUPR09MB053.namprd09.prod.outlook.com> References: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F54ED5@eusaamb109.ericsson.se> In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F54ED5@eusaamb109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.140.100] x-forefront-prvs: 0100732B76 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(13464003)(189002)(199002)(164054003)(51704005)(377454003)(19580405001)(74706001)(83322001)(50986001)(46102001)(54356001)(33646001)(66066001)(51856001)(86362001)(47736001)(19580395003)(74876001)(85306002)(65816001)(83072002)(85852003)(53806001)(80022001)(47976001)(2656002)(92566001)(93136001)(74366001)(81686001)(74316001)(90146001)(93516002)(80976001)(56816005)(81342001)(87936001)(76482001)(49866001)(47446002)(59766001)(81542001)(74502001)(81816001)(79102001)(87266001)(31966008)(76576001)(63696002)(77096001)(77982001)(54316002)(4396001)(74662001)(56776001)(76796001)(76786001)(69226001)(94316002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR09MB053; H:BLUPR09MB053.namprd09.prod.outlook.com; CLIP:129.6.140.100; FPR:; MLV:nspm; InfoNoRecordsMX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 16:11:07 -0000 Thanks, Jakob. Your interpretation is helpful and Kuyur agrees. So that's g= ood. >The intent in the draft is to allow the receiver to delete stale routes up= on receipt >of the EoRR. Yes, and it seems the intent is even more flexible than that. >From Section 4: "An implementation MAY impose a locally configurable upper bound on how long it would retain any stale routes. Once the upper bound is reached, the implementation MAY remove any routes from the peer that are still marked as stale for that without waiting for an EoRR message." Just to clarify (for the chairs): I support the draft advancing to RFC. Sriram >-----Original Message----- >From: Jakob Heitz [mailto:jakob.heitz@ericsson.com] >Sent: Wednesday, January 22, 2014 3:49 PM >To: Sriram, Kotikalapudi; idr@ietf.org; "Keyur Patel (keyupate)" >Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh > >My interpretation: > >It means the implementation does not have to do a snapshot. >If a route changes during the refresh (after BoRR, before EoRR), it is an >implementation decision whether to advertise just the latest version of th= e >route or also the older version. > >Suppose a speaker sends BoRR, then sends an update for a particular route, >then that route changes, then the speaker sends updates for other routes, = then >it sends EoRR. The final change to the particular route may be sent before= or >after the EoRR. > >In another scenario, a speaker sends BoRR and starts advertising routes. >Then a particular route that has not yet been advertised as part of the re= fresh >changes. >It is an implementation decision whether to just advertise the latest vers= ion of >the route or the original version. The latest version must be advertised e= ither >before or after the EoRR. At least one version of the route must be advert= ised >before the EoRR. > >What it means is that an implementation is free to consider an incoming ro= ute >change to have happened before, during or after the refresh operation. > >The intent in the draft is to allow the receiver to delete stale routes up= on receipt >of the EoRR. > >Thanks, >Jakob. > From jakob.heitz@ericsson.com Thu Jan 23 08:54:04 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 618201A008E for ; Thu, 23 Jan 2014 08:54:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNMu3Y_q0yL3 for ; Thu, 23 Jan 2014 08:54:01 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id ECCE01A007C for ; Thu, 23 Jan 2014 08:54:00 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-60-52e14924a655 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id B7.4D.12743.42941E25; Thu, 23 Jan 2014 17:53:57 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0387.000; Thu, 23 Jan 2014 11:53:59 -0500 From: Jakob Heitz To: "Sriram, Kotikalapudi" Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPF5KdKHMolEg8TF26AxOKep0T6JqRMOhAgAGfMAD//7gu+w== Date: Thu, 23 Jan 2014 16:53:59 +0000 Message-ID: <98FB84F8-96B2-4D7B-8FF0-0A3DE4D90465@ericsson.com> References: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F54ED5@eusaamb109.ericsson.se>, <10eca092172d443380eccf2e8548f2a9@BLUPR09MB053.namprd09.prod.outlook.com> In-Reply-To: <10eca092172d443380eccf2e8548f2a9@BLUPR09MB053.namprd09.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyuXRPiK6q58Mggx0zuCxe3X7GZNG49Tyb xeQ9d1gdmD2m/N7I6rFkyU8mj2sn/7IGMEdx2aSk5mSWpRbp2yVwZay50MBe0CNTce5DcQPj GrEuRk4OCQETib7NPYwQtpjEhXvr2boYuTiEBI4wSixYtJMVJCEksJxR4n+vHojNJqAj8e16 FzOILSJgKbHp7iU2EJtZIEhi4qVzYHFhATeJV5OWs0PUuEu0/JgEVe8ksXXBNxYQm0VAVeLi oZ1gcV4Be4lHLYfYIRZPYJKY03EdbCinQJjEt1kXwAYxAl33/dQaJohl4hK3nsxngrhaQGLJ nvPMELaoxMvH/1ghanQkFuz+BHWctsSyha+hlglKnJz5hGUCo+gsJKNmIWmZhaRlFpKWBYws qxg5SotTy3LTjQw2MQIj5JgEm+4Oxj0vLQ8xSnOwKInzfnnrHCQkkJ5YkpqdmlqQWhRfVJqT WnyIkYmDU6qBsZan87bebd5YvcRD7w91JXifvNNwTs3/S3Yo+3pr3zli8myTloezptZGpN6x Ek57eLmifKnmViO///Ojgwzq9CZO239fOf/v5JkGaS+Z17ExMzUf1jh/KjzkRWqbzi6ln4KV H1ZOL5jbEzKLOSbbUo5NKfJvxds7J6RY1VyNza+FTDuz7RaTEktxRqKhFnNRcSIAJGqsil4C AAA= Cc: "Keyur Patel \(keyupate\)" , "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 16:54:04 -0000 Other cases: A speaker should never send an EoRR without first having sent a BoRR. A speaker can not "nest" refreshes. I.e. it should not send two BoRR withou= t an intervening EoRR or send two EoRR without an intervening BoRR. Note th= at the behavior of a receiving speaker in the face of such attempted nestin= g "just works" with the rules stated in the draft. A refresh cannot last through a graceful restart. I.e. a speaker can not se= nd BoRR, then reset the session, start a new session with graceful restart,= then send an EoRR. A session reset must cancel any stale markings due to a= previous BoRR. Of course, if graceful restart is in effect, then everythin= g gets stale marked again. A speaker must not send BoRR before having sent EoR (to complete a GR). If a speaker receives a BoRR, before having received an EoR on a session wi= th GR enabled, it should ignore the BoRR and log an error. At least, that's= what I would do. I really don't think it's worth inventing two separate st= ale marks, one for GR and one for ERR, just to handle this case. Other opin= ions? -- Jakob Heitz. > On Jan 23, 2014, at 8:11 AM, "Sriram, Kotikalapudi" wrote: >=20 > Thanks, Jakob. Your interpretation is helpful and Kuyur agrees. So that's= good. >=20 >> The intent in the draft is to allow the receiver to delete stale routes = upon receipt >> of the EoRR. >=20 > Yes, and it seems the intent is even more flexible than that. > From Section 4: > "An implementation MAY impose a locally configurable upper bound on > how long it would retain any stale routes. Once the upper bound is > reached, the implementation MAY remove any routes from the peer that > are still marked as stale for that without waiting for an > EoRR message." >=20 > Just to clarify (for the chairs): I support the draft advancing to RFC. >=20 > Sriram >=20 >=20 >=20 >> -----Original Message----- >> From: Jakob Heitz [mailto:jakob.heitz@ericsson.com] >> Sent: Wednesday, January 22, 2014 3:49 PM >> To: Sriram, Kotikalapudi; idr@ietf.org; "Keyur Patel (keyupate)" >> Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh >>=20 >> My interpretation: >>=20 >> It means the implementation does not have to do a snapshot. >> If a route changes during the refresh (after BoRR, before EoRR), it is a= n >> implementation decision whether to advertise just the latest version of = the >> route or also the older version. >>=20 >> Suppose a speaker sends BoRR, then sends an update for a particular rout= e, >> then that route changes, then the speaker sends updates for other routes= , then >> it sends EoRR. The final change to the particular route may be sent befo= re or >> after the EoRR. >>=20 >> In another scenario, a speaker sends BoRR and starts advertising routes. >> Then a particular route that has not yet been advertised as part of the = refresh >> changes. >> It is an implementation decision whether to just advertise the latest ve= rsion of >> the route or the original version. The latest version must be advertised= either >> before or after the EoRR. At least one version of the route must be adve= rtised >> before the EoRR. >>=20 >> What it means is that an implementation is free to consider an incoming = route >> change to have happened before, during or after the refresh operation. >>=20 >> The intent in the draft is to allow the receiver to delete stale routes = upon receipt >> of the EoRR. >>=20 >> Thanks, >> Jakob. >>=20 From chris.hall@highwayman.com Thu Jan 23 09:35:40 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD031A001A for ; Thu, 23 Jan 2014 09:35:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.56 X-Spam-Level: * X-Spam-Status: No, score=1.56 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Exs4TJqAin8y for ; Thu, 23 Jan 2014 09:35:37 -0800 (PST) Received: from smtp.demon.co.uk (mdfmta005.mxout.tch.inty.net [91.221.169.46]) by ietfa.amsl.com (Postfix) with ESMTP id 541F81A0015 for ; Thu, 23 Jan 2014 09:35:36 -0800 (PST) Received: from mdfmta005.tch.inty.net (unknown [127.0.0.1]) by mdfmta005.tch.inty.net (Postfix) with ESMTP id 3C65718C401; Thu, 23 Jan 2014 17:35:34 +0000 (GMT) Received: from mdfmta005.tch.inty.net (unknown [127.0.0.1]) by mdfmta005.tch.inty.net (Postfix) with ESMTP id 1D0BE18C8EC; Thu, 23 Jan 2014 17:35:29 +0000 (GMT) Received: from hestia.halldom.com (unknown [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta005.tch.inty.net (Postfix) with ESMTP; Thu, 23 Jan 2014 17:35:27 +0000 (GMT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by hestia.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1W6OBU-00074Y-E2; Thu, 23 Jan 2014 17:35:20 +0000 From: "Chris Hall" To: References: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F54ED5@eusaamb109.ericsson.se>, <10eca092172d443380eccf2e8548f2a9@BLUPR09MB053.namprd09.prod.outlook.com> <98FB84F8-96B2-4D7B-8FF0-0A3DE4D90465@ericsson.com> In-Reply-To: <98FB84F8-96B2-4D7B-8FF0-0A3DE4D90465@ericsson.com> Date: Thu, 23 Jan 2014 17:35:14 -0000 Organization: Highwayman Message-ID: <07a101cf1861$7cf46700$76dd3500$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQG//zNq4hUhbREFIybMDiQfLPKfmwIlA/HBAjQliZgBA79uvgEPvMpImn1b2lA= Content-Language: en-gb X-MDF-HostID: 18 Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 17:35:40 -0000 Jakob Heitz wrote (on Thu 23-Jan-2014 at 16:54 +0000): ... > If a speaker receives a BoRR, before having received an EoR on a > session with GR enabled, it should ignore the BoRR and log an > error. At least, that's what I would do. I really don't think it's > worth inventing two separate stale marks, one for GR and one for > ERR, just to handle this case. Other opinions? Does EoRR mean something actually different to EoR ? >From the receiver's perspective both mean that any (remaining) stale routes must now be banged on the head. After a restart, EoR may be the trigger for other work which has been deferred to this point, but the receiver can work that much out for itself. Chris From jakob.heitz@ericsson.com Thu Jan 23 10:38:03 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8BAF1A01F4 for ; Thu, 23 Jan 2014 10:38:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKSniwcXVqkb for ; Thu, 23 Jan 2014 10:37:59 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 00A8F1A01AB for ; Thu, 23 Jan 2014 10:37:58 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-37-52e1618364e4 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 4D.C3.12743.38161E25; Thu, 23 Jan 2014 19:37:55 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0387.000; Thu, 23 Jan 2014 13:37:57 -0500 From: Jakob Heitz To: Chris Hall , "idr@ietf.org" Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPF5KdKHMolEg8TF26AxOKep0T6JqRMOhAgAGfMAD//7gu+4AAX1gA//+1BTA= Date: Thu, 23 Jan 2014 18:37:57 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F55B8C@eusaamb109.ericsson.se> References: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F54ED5@eusaamb109.ericsson.se>, <10eca092172d443380eccf2e8548f2a9@BLUPR09MB053.namprd09.prod.outlook.com> <98FB84F8-96B2-4D7B-8FF0-0A3DE4D90465@ericsson.com> <07a101cf1861$7cf46700$76dd3500$@highwayman.com> In-Reply-To: <07a101cf1861$7cf46700$76dd3500$@highwayman.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsUyuXSPn25z4sMgg4aFohbvf21jtnh1+xmT A5PH8aO7mD2WLPnJFMAUxWWTkpqTWZZapG+XwJWxpnsec8ErjoqZ9z6wNTB2s3cxcnJICJhI rN/VygZhi0lcuLcezBYSOMIocfRSUhcjF5C9nFHi1OydzCAJNgEdiW/Xu8BsEQFPiZfvrrCA 2MICbhJ3Wz4zQcTdJVp+TIKq8ZPoPboJrIZFQFXiyIoTYAt4BXwlJj48ywKx4A+TxOXDTWAX cQrYSvz+sRismRHoou+n1oANZRYQl7j1ZD4TxKUCEkv2nGeGsEUlXj7+xwphK0lMWnqOFaJe R2LB7k9sELa2xLKFr5khFgtKnJz5hGUCo+gsJGNnIWmZhaRlFpKWBYwsqxg5SotTy3LTjQw2 MQLj4ZgEm+4Oxj0vLQ8xSnOwKInzfnnrHCQkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBUXrW r6+nGWcnTrJT9K+r///71Yxz4W4tqz2tV524eSOJtTmM+5m07uy2OcHWsfde7mHR8j1vsvJj fb3EgoMrX55LYVtyj71CWufLet/Lz96+bSnNX/ppxvxiEeNNcee8tdbf12ztyiqc3JzVe+uo nkftBvnVT6pP2t92fLA87IHMpjVBfcpMfUosxRmJhlrMRcWJAJjcRttVAgAA Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 18:38:04 -0000 Oh, another case: A route refresh request is received before the EoR is sent. I'll retract my statement to ignore BoRR before EoR is received. Thanks, Jakob. -----Original Message----- From: Chris Hall [mailto:chris.hall@highwayman.com]=20 Sent: Thursday, January 23, 2014 9:35 AM To: idr@ietf.org Cc: Jakob Heitz Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Jakob Heitz wrote (on Thu 23-Jan-2014 at 16:54 +0000): ... > If a speaker receives a BoRR, before having received an EoR on a=20 > session with GR enabled, it should ignore the BoRR and log an error.=20 > At least, that's what I would do. I really don't think it's worth=20 > inventing two separate stale marks, one for GR and one for ERR, just=20 > to handle this case. Other opinions? Does EoRR mean something actually different to EoR ? >From the receiver's perspective both mean that any (remaining) stale routes= must now be banged on the head. After a restart, EoR may be the trigger f= or other work which has been deferred to this point, but the receiver can w= ork that much out for itself. Chris From internet-drafts@ietf.org Thu Jan 23 10:58:42 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5677A1A00FF; Thu, 23 Jan 2014 10:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Isz2TEDvPrg; Thu, 23 Jan 2014 10:58:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A11E1A01FC; Thu, 23 Jan 2014 10:58:10 -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: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140123185810.25318.69032.idtracker@ietfa.amsl.com> Date: Thu, 23 Jan 2014 10:58:10 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp4-mibv2-tc-mib-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 18:58:42 -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 : Definitions of Textual Conventions for the Manage= ment of the Fourth Version of Border Gateway Protocol (BGP-4) Author : Jeffrey Haas Filename : draft-ietf-idr-bgp4-mibv2-tc-mib-05.txt Pages : 6 Date : 2014-01-23 Abstract: This memo defines a portion of the Management Information Base (MIB) which defines Textual Conventions for the management of BGP-4. The intent is that these textual conventions will be used in BGP-related MIB modules that would otherwise define their own representations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp4-mibv2-tc-mib/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-bgp4-mibv2-tc-mib-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-bgp4-mibv2-tc-mib-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Thu Jan 23 10:59:09 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0139D1A0223; Thu, 23 Jan 2014 10:59:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oxv3f7vMjv3e; Thu, 23 Jan 2014 10:59:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B16C1A0219; Thu, 23 Jan 2014 10:58:31 -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: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140123185830.24380.34262.idtracker@ietfa.amsl.com> Date: Thu, 23 Jan 2014 10:58:30 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp4-mibv2-15.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 18:59: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 : Definitions of Managed Objects for the Fourth Ver= sion of Border Gateway Protocol (BGP-4), Second Version Author : Jeffrey Haas Filename : draft-ietf-idr-bgp4-mibv2-15.txt Pages : 45 Date : 2014-01-23 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing the Border Gateway Protocol, Version 4. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp4-mibv2/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-bgp4-mibv2-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-bgp4-mibv2-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From chris.hall@highwayman.com Thu Jan 23 12:17:54 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C081A007C for ; Thu, 23 Jan 2014 12:17:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.16 X-Spam-Level: X-Spam-Status: No, score=0.16 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhC_dTV5aKe3 for ; Thu, 23 Jan 2014 12:17:52 -0800 (PST) Received: from smtp.demon.co.uk (mdfmta005.mxout.tbr.inty.net [91.221.168.46]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8EF1A0049 for ; Thu, 23 Jan 2014 12:17:51 -0800 (PST) Received: from mdfmta005.tbr.inty.net (unknown [127.0.0.1]) by mdfmta005.tbr.inty.net (Postfix) with ESMTP id 7902CA64A1C; Thu, 23 Jan 2014 20:17:50 +0000 (GMT) Received: from mdfmta005.tbr.inty.net (unknown [127.0.0.1]) by mdfmta005.tbr.inty.net (Postfix) with ESMTP id 54861A6492C; Thu, 23 Jan 2014 20:17:50 +0000 (GMT) Received: from hestia.halldom.com (unknown [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta005.tbr.inty.net (Postfix) with ESMTP; Thu, 23 Jan 2014 20:17:49 +0000 (GMT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by hestia.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1W6Qii-00074k-TX; Thu, 23 Jan 2014 20:17:48 +0000 From: "Chris Hall" To: References: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F54ED5@eusaamb109.ericsson.se>, <10eca092172d443380eccf2e8548f2a9@BLUPR09MB053.namprd09.prod.outlook.com> <98FB84F8-96B2-4D7B-8FF0-0A3DE4D90465@ericsson.com> <07a101cf1861$7cf46700$76dd3500$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F55B8C@eusaamb109.ericsson.se> In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F55B8C@eusaamb109.ericsson.se> Date: Thu, 23 Jan 2014 20:17:42 -0000 Organization: Highwayman Message-ID: <07c701cf1878$2f67aee0$8e370ca0$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQG//zNq4hUhbREFIybMDiQfLPKfmwIlA/HBAjQliZgBA79uvgEPvMpIAkI1woMBcE7Ne5pf3jrA Content-Language: en-gb X-MDF-HostID: 8 Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 20:17:54 -0000 Jakob Heitz wrote (on Thu 23-Jan-2014 at 18:38 +0000): ... > Oh, another case: > A route refresh request is received before the EoR is sent. > I'll retract my statement to ignore BoRR before EoR is received. So... there are two operations: (1) mark everything received "stale", and set stale-timer. (2) flush anything which is still "stale", and stop stale-timer. (3) wait for BoRR, process UPDATEs but ignore EoR. Receiving BoRR => (1). Restarting gracefully => (1). EoR => (2) (and perhaps some other stuff). Timing out => (2). Sending route-refresh request (RRQ) => (3) -- so that: a) if is restarting gracefully (so EoR not yet received or processed) then is not confused by an EoR rolling up -- the BoRR signals start of response RRQ. On receipt of an RRQ, the receiver sends BoRR and starts sending from the beginning. b) similarly if is in the middle of a route-refresh (RR) started by an earlier RRQ or one initiated by the other end sending a BoRR. c) if an RRQ crosses with a BoRR initiated at the other end, the sender of the BoRR has to go back to the beginning, and send another BoRR. The sender of the RRQ interprets the two incoming BoRRs as (1) response to RRQ, and then (2) RR initiated by far end. The sender of the BoRR thinks the two outgoing BoRRs are (1) initiate RR, and then (2) respond to RRQ. Some effort has been wasted, tant pis. Or is there something I'm missing ? If an RRQ is sent, but no BoRR rolls up in a timely fashion... does the sender of the RRQ treat everything as stale and flush the lot, or does it proceed with what it has... does it send another RRQ, what ? Clearly it whimpers, logging-wise or other-wise. [One thing: suppose the sending side of the RR has a number of pending UPDATEs when it receives the RRQ. I suppose it makes sense to send those first, before sending the rest -- given that the pending UPDATEs represent actual changes, while the rest is generally going to simply freshen the ones marked stale ? Any UPDATEs that arrive after sending RRQ, but before receiving BoRR, can be processed into the RIB, and marked stale when the BoRR does arrive. I guess the sending side of the RR could hold off sending the BoRR until it has emptied any pending UPDATEs queue.] Chris > Thanks, > Jakob. > > -----Original Message----- > From: Chris Hall [mailto:chris.hall@highwayman.com] > Sent: Thursday, January 23, 2014 9:35 AM > To: idr@ietf.org > Cc: Jakob Heitz > Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route- > refresh > > Jakob Heitz wrote (on Thu 23-Jan-2014 at 16:54 +0000): > ... > > If a speaker receives a BoRR, before having received an EoR on a > > session with GR enabled, it should ignore the BoRR and log an > error. > > At least, that's what I would do. I really don't think it's worth > > inventing two separate stale marks, one for GR and one for ERR, > just > > to handle this case. Other opinions? > > Does EoRR mean something actually different to EoR ? > > From the receiver's perspective both mean that any (remaining) > stale routes must now be banged on the head. After a restart, EoR > may be the trigger for other work which has been deferred to this > point, but the receiver can work that much out for itself. > > Chris From jakob.heitz@ericsson.com Thu Jan 23 12:39:15 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377051A01CD for ; Thu, 23 Jan 2014 12:39:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIZd2DutwbDN for ; Thu, 23 Jan 2014 12:39:11 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 332191A00C5 for ; Thu, 23 Jan 2014 12:39:11 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-fa-52e17ded9753 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 4D.0D.11484.DED71E25; Thu, 23 Jan 2014 21:39:10 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0387.000; Thu, 23 Jan 2014 15:39:07 -0500 From: Jakob Heitz To: Chris Hall , "idr@ietf.org" Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPF5KdKHMolEg8TF26AxOKep0T6JqRMOhAgAGfMAD//7gu+4AAX1gA//+1BTCAAHhgAP//sQGg Date: Thu, 23 Jan 2014 20:39:07 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F55E37@eusaamb109.ericsson.se> References: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F54ED5@eusaamb109.ericsson.se>, <10eca092172d443380eccf2e8548f2a9@BLUPR09MB053.namprd09.prod.outlook.com> <98FB84F8-96B2-4D7B-8FF0-0A3DE4D90465@ericsson.com> <07a101cf1861$7cf46700$76dd3500$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F55B8C@eusaamb109.ericsson.se> <07c701cf1878$2f67aee0$8e370ca0$@highwayman.com> In-Reply-To: <07c701cf1878$2f67aee0$8e370ca0$@highwayman.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMLMWRmVeSWpSXmKPExsUyuXRPgu672odBBt/WM1u8/7WN2eLV7WdM Dkwex4/uYvZYsuQnUwBTFJdNSmpOZllqkb5dAlfG4/PfWQp+y1X87zvN3sDYINHFyMkhIWAi cendOTYIW0ziwr31QDYXh5DAEUaJTzcOs0A4yxkleo4eZwKpYhPQkfh2vYsZxBYR8JR4+e4K C4gtLOAmcbflMxNE3F2i5cckqJooifmTP4PVsAioSkyePY0VxOYV8JV4vOshO8SCz8wSv193 soMkOAVsJfrmHmAEsRmBTvp+ag3YUGYBcYlbT+YzQZwqILFkz3lmCFtU4uXjf6wQtpLEpKXn WCHqdSQW7P7EBmFrSyxb+JoZYrGgxMmZT1gmMIrOQjJ2FpKWWUhaZiFpWcDIsoqRo7Q4tSw3 3chwEyMwIo5JsDnuYFzwyfIQozQHi5I475e3zkFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUa GAX3bCpQaWTrXVBlYSt3c65viuiK/iu3BT4Jb8hbMvfJG6XWgEDlyrehciUdrn573V/Wf9ge tDboc8mfXwZL1AyyP/FvVxV+GbHX5aW3eVRAyczThUqaR5asnXvHUdf7v06pxVsRhgnFSj9q mVfqSay88fdMUVnylvb32jPkfAymeTSe/L/ojhJLcUaioRZzUXEiAOdggchWAgAA Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 20:39:15 -0000 No (3) needed. Then there is no message crossing problem. Either EoR or EoRR deletes the stales. The sender of the routes needs to ensure that it sends all routes again aft= er sending BoRR before sending either Eor or EoRR. Thanks, Jakob. -----Original Message----- From: Chris Hall [mailto:chris.hall@highwayman.com]=20 Sent: Thursday, January 23, 2014 12:18 PM To: idr@ietf.org Cc: Jakob Heitz Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Jakob Heitz wrote (on Thu 23-Jan-2014 at 18:38 +0000): ... > Oh, another case: > A route refresh request is received before the EoR is sent. > I'll retract my statement to ignore BoRR before EoR is received. So... there are two operations: (1) mark everything received "stale", and set stale-timer. (2) flush anything which is still "stale", and stop stale-timer. (3) wait for BoRR, process UPDATEs but ignore EoR. Receiving BoRR =3D> (1). Restarting gracefully =3D> (1). EoR =3D> (2) (and perhaps some other stuff). Timing out =3D> (2). Sending route-refresh request (RRQ) =3D> (3) -- so that: a) if is restarting gracefully (so EoR not yet received or processed) then is not confused by an EoR rolling up -- the BoRR signals start of response RRQ. On receipt of an RRQ, the receiver sends BoRR and starts sending from the beginning. b) similarly if is in the middle of a route-refresh (RR) started by an earlier RRQ or one initiated by the other end sending a BoRR. c) if an RRQ crosses with a BoRR initiated at the other=20 end, the sender of the BoRR has to go back to the beginning, and send another BoRR. The sender of the RRQ interprets the two incoming BoRRs as (1) response to RRQ, and then (2) RR initiated by far end. The sender of the BoRR thinks the two outgoing BoRRs are (1) initiate RR, and then (2) respond to RRQ. Some effort has been wasted, tant pis. Or is there something I'm missing ? If an RRQ is sent, but no BoRR rolls up in a timely fashion... does the sen= der of the RRQ treat everything as stale and flush the lot, or does it proc= eed with what it has... does it send another RRQ, what ? Clearly it whimpers, logging-wise or other-wise. [One thing: suppose the sending side of the RR has a number of pending UPDA= TEs when it receives the RRQ. I suppose it makes sense to send those first= , before sending the rest -- given that the pending UPDATEs represent actua= l changes, while the rest is generally going to simply freshen the ones mar= ked stale ? Any UPDATEs that arrive after sending RRQ, but before receivin= g BoRR, can be processed into the RIB, and marked stale when the BoRR does = arrive. I guess the sending side of the RR could hold off sending the BoRR= until it has emptied any pending UPDATEs queue.] Chris > Thanks, > Jakob. >=20 > -----Original Message----- > From: Chris Hall [mailto:chris.hall@highwayman.com] > Sent: Thursday, January 23, 2014 9:35 AM > To: idr@ietf.org > Cc: Jakob Heitz > Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route- > refresh >=20 > Jakob Heitz wrote (on Thu 23-Jan-2014 at 16:54 +0000): > ... > > If a speaker receives a BoRR, before having received an EoR on a=20 > > session with GR enabled, it should ignore the BoRR and log an > error. > > At least, that's what I would do. I really don't think it's worth=20 > > inventing two separate stale marks, one for GR and one for ERR, > just > > to handle this case. Other opinions? >=20 > Does EoRR mean something actually different to EoR ? >=20 > From the receiver's perspective both mean that any (remaining) stale=20 > routes must now be banged on the head. After a restart, EoR may be=20 > the trigger for other work which has been deferred to this point, but=20 > the receiver can work that much out for itself. >=20 > Chris From chris.hall@highwayman.com Thu Jan 23 14:30:11 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3811A0154 for ; Thu, 23 Jan 2014 14:30:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.16 X-Spam-Level: X-Spam-Status: No, score=0.16 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-hBd2dpYoGY for ; Thu, 23 Jan 2014 14:30:09 -0800 (PST) Received: from smtp.demon.co.uk (mdfmta009.mxout.tch.inty.net [91.221.169.50]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC3D1A012E for ; Thu, 23 Jan 2014 14:30:08 -0800 (PST) Received: from mdfmta009.tch.inty.net (unknown [127.0.0.1]) by mdfmta009.tch.inty.net (Postfix) with ESMTP id 3C73F128077; Thu, 23 Jan 2014 22:30:06 +0000 (GMT) Received: from mdfmta009.tch.inty.net (unknown [127.0.0.1]) by mdfmta009.tch.inty.net (Postfix) with ESMTP id 5BA391280A7; Thu, 23 Jan 2014 22:30:05 +0000 (GMT) Received: from hestia.halldom.com (unknown [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta009.tch.inty.net (Postfix) with ESMTP; Thu, 23 Jan 2014 22:30:04 +0000 (GMT) Received: from gmch-ipad-w.halldom.com ([80.177.246.149]) by hestia.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1W6Smh-00074y-31; Thu, 23 Jan 2014 22:30:03 +0000 References: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F54ED5@eusaamb109.ericsson.se> <10eca092172d443380eccf2e8548f2a9@BLUPR09MB053.namprd09.prod.outlook.com> <98FB84F8-96B2-4D7B-8FF0-0A3DE4D90465@ericsson.com> <07a101cf1861$7cf46700$76dd3500$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F55B8C@eusaamb109.ericsson.se> <07c701cf1878$2f67aee0$8e370ca0$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F55E37@eusaamb109.ericsson.se> Mime-Version: 1.0 (1.0) In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F55E37@eusaamb109.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <13E5680B-7295-4C05-B913-C5339993FA32@highwayman.com> X-Mailer: iPad Mail (10B329) From: Chris Hall Date: Thu, 23 Jan 2014 22:29:57 +0000 To: "idr@ietf.org" X-MDF-HostID: 22 Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 22:30:11 -0000 On 23 Jan 2014, at 20:39 +0000, Jakob Heitz wrote: > No (3) needed. OK... having negotiated enhanced-rr, sending RRQ has no effect on staleness o= f routes, or much of anything else. Now only incoming BoRR and a graceful r= estart set stale. EoR flushes stale. [This is a change of behaviour for RRQ... which is OK. The receiver of the R= RQ has promised to support enhanced-rr, so can be depended on to send BoRR i= n due course.] I guess BoRR need not flush existing stale, but in that case it should not s= top an existing stale-timer. (This is similar to not flushing stale if grac= efully restarts in the middle of a graceful restart -- or an enhanced-rr, fo= r that matter.) The sender of the BoRR could send an EoR first if it wanted= to force the issue, though in turn the receiver could ignore EoR before BoR= R if it has sent an RRQ. > Then there is no message crossing problem. OK... given that RRQ has no effect on state, it doesn't matter if the far en= d is psychic, and sends BoRR before it sees the RRQ :-) > Either EoR or EoRR deletes the stales. > The sender of the routes needs to ensure that it sends all routes again af= ter sending BoRR before sending either Eor or EoRR. I remain puzzled as to the need for EoRR. Chris > Thanks, > Jakob. >=20 > -----Original Message----- > From: Chris Hall [mailto:chris.hall@highwayman.com]=20 > Sent: Thursday, January 23, 2014 12:18 PM > To: idr@ietf.org > Cc: Jakob Heitz > Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh >=20 > Jakob Heitz wrote (on Thu 23-Jan-2014 at 18:38 +0000): > ... >> Oh, another case: >> A route refresh request is received before the EoR is sent. >> I'll retract my statement to ignore BoRR before EoR is received. >=20 > So... there are two operations: >=20 > (1) mark everything received "stale", and set stale-timer. >=20 > (2) flush anything which is still "stale", and stop stale-timer. >=20 > (3) wait for BoRR, process UPDATEs but ignore EoR. >=20 > Receiving BoRR =3D> (1). >=20 > Restarting gracefully =3D> (1). >=20 > EoR =3D> (2) (and perhaps some other stuff). >=20 > Timing out =3D> (2). >=20 > Sending route-refresh request (RRQ) =3D> (3) -- so that: >=20 > a) if is restarting gracefully (so EoR not yet received > or processed) then is not confused by an EoR rolling > up -- the BoRR signals start of response RRQ. >=20 > On receipt of an RRQ, the receiver sends BoRR and > starts sending from the beginning. >=20 > b) similarly if is in the middle of a route-refresh (RR) > started by an earlier RRQ or one initiated by the > other end sending a BoRR. >=20 > c) if an RRQ crosses with a BoRR initiated at the other=20 > end, the sender of the BoRR has to go back to the > beginning, and send another BoRR. >=20 > The sender of the RRQ interprets the two incoming BoRRs > as (1) response to RRQ, and then (2) RR initiated by > far end. >=20 > The sender of the BoRR thinks the two outgoing BoRRs > are (1) initiate RR, and then (2) respond to RRQ. >=20 > Some effort has been wasted, tant pis. >=20 > Or is there something I'm missing ? >=20 > If an RRQ is sent, but no BoRR rolls up in a timely fashion... does the se= nder of the RRQ treat everything as stale and flush the lot, or does it proc= eed with what it has... does it send another RRQ, what ? > Clearly it whimpers, logging-wise or other-wise. >=20 > [One thing: suppose the sending side of the RR has a number of pending UPD= ATEs when it receives the RRQ. I suppose it makes sense to send those first= , before sending the rest -- given that the pending UPDATEs represent actual= changes, while the rest is generally going to simply freshen the ones marke= d stale ? Any UPDATEs that arrive after sending RRQ, but before receiving B= oRR, can be processed into the RIB, and marked stale when the BoRR does arri= ve. I guess the sending side of the RR could hold off sending the BoRR unti= l it has emptied any pending UPDATEs queue.] >=20 > Chris >=20 >> Thanks, >> Jakob. >>=20 >> -----Original Message----- >> From: Chris Hall [mailto:chris.hall@highwayman.com] >> Sent: Thursday, January 23, 2014 9:35 AM >> To: idr@ietf.org >> Cc: Jakob Heitz >> Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route- >> refresh >>=20 >> Jakob Heitz wrote (on Thu 23-Jan-2014 at 16:54 +0000): >> ... >>> If a speaker receives a BoRR, before having received an EoR on a=20 >>> session with GR enabled, it should ignore the BoRR and log an >> error. >>> At least, that's what I would do. I really don't think it's worth=20 >>> inventing two separate stale marks, one for GR and one for ERR, >> just >>> to handle this case. Other opinions? >>=20 >> Does EoRR mean something actually different to EoR ? >>=20 >> =46rom the receiver's perspective both mean that any (remaining) stale=20= >> routes must now be banged on the head. After a restart, EoR may be=20 >> the trigger for other work which has been deferred to this point, but=20 >> the receiver can work that much out for itself. >>=20 >> Chris >=20 From keyupate@cisco.com Thu Jan 23 15:53:51 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FBF11A0467 for ; Thu, 23 Jan 2014 15:53:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIPC8S8yS85o for ; Thu, 23 Jan 2014 15:53:50 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id AFD0D1A0449 for ; Thu, 23 Jan 2014 15:53:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=623; q=dns/txt; s=iport; t=1390521230; x=1391730830; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=5Nya74y5H+CHRwOYV2s4jXTAOSz1MdLb+vUGwJuovsU=; b=MfLaduaR3gLEUWTymdZ/nOOkeWjYqrdmt9LlEQtBrrb/FlUCXFqKBaMY JDTrvPr5BcguLdUHc0Cbm7hlPc47teNG2KwUxCN624OFTFTXjvDBDaxU5 cLyGnbpt1LBSUXTT/nMBGeMtPjGzw9AhFaTdSo7HerMg4fbF9dioa6pej U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFANuq4VKtJV2Z/2dsb2JhbABagwyBDrwzgRAWdIIsOlEBCDZCJQIEAYgXxxYXjweEOAEDmCOSGIMtgio X-IronPort-AV: E=Sophos;i="4.95,709,1384300800"; d="scan'208";a="299435938" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 23 Jan 2014 23:53:49 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0NNrnD0014484 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Jan 2014 23:53:49 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.228]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Thu, 23 Jan 2014 17:53:49 -0600 From: "Keyur Patel (keyupate)" To: Chris Hall , "idr@ietf.org" Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPGJZcnSg2v8KK+0+W7r0WcIWGPQ== Date: Thu, 23 Jan 2014 23:53:48 +0000 Message-ID: In-Reply-To: <13E5680B-7295-4C05-B913-C5339993FA32@highwayman.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [128.107.163.80] Content-Type: text/plain; charset="us-ascii" Content-ID: <0DC9E23146BD884087404757EE6DBF25@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 23:53:51 -0000 [Trimming the remaining message & hoping that I am not answering out of context] :) Hi Chris, > >I remain puzzled as to the need for EoRR. > >Chris As per RFC4724, EOR is signaled to indicate exchange of initial Routing table updates. Amongst other things (as you indicated), implementations are required to defer route selection process till EOR is received. EORR on other hand indicates exchange of subsequent Routing table updates. Both of them are enabled using different capabilities. We believe they have different semantics and wanted to avoid overloading EOR. Best Regards, Keyur From jakob.heitz@ericsson.com Thu Jan 23 16:07:18 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4D8B1A048E for ; Thu, 23 Jan 2014 16:07:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FE3s8piUF7kQ for ; Thu, 23 Jan 2014 16:07:16 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 86EE81A0485 for ; Thu, 23 Jan 2014 16:07:16 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-f5-52e1aeb087ad Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id E0.D4.12743.0BEA1E25; Fri, 24 Jan 2014 01:07:12 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0387.000; Thu, 23 Jan 2014 19:07:15 -0500 From: Jakob Heitz To: Chris Hall , "idr@ietf.org" Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPF5KdKHMolEg8TF26AxOKep0T6JqRMOhAgAGfMAD//7gu+4AAX1gA//+1BTCAAHhgAP//sQGgAA5+ToAABygAoA== Date: Fri, 24 Jan 2014 00:07:14 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F56346@eusaamb109.ericsson.se> References: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F54ED5@eusaamb109.ericsson.se> <10eca092172d443380eccf2e8548f2a9@BLUPR09MB053.namprd09.prod.outlook.com> <98FB84F8-96B2-4D7B-8FF0-0A3DE4D90465@ericsson.com> <07a101cf1861$7cf46700$76dd3500$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F55B8C@eusaamb109.ericsson.se> <07c701cf1878$2f67aee0$8e370ca0$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F55E37@eusaamb109.ericsson.se> <13E5680B-7295-4C05-B913-C5339993FA32@highwayman.com> In-Reply-To: <13E5680B-7295-4C05-B913-C5339993FA32@highwayman.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyuXRPiO6GdQ+DDFZ+07B4/2sbs8Wr28+Y HJg8jh/dxeyxZMlPpgCmKC6blNSczLLUIn27BK6MK0cMC7YyV7Q3zmdtYLzN1MXIySEhYCJx e/8cFghbTOLCvfVsXYxcHEICRxgl1rddZ4dwljNK7DzzCKyDTUBH4tv1LmYQW0TAU+Lluytg 3cICbhJ3Wz4zQcTdJVp+TIKqyZLoOXMLaBAHB4uAqsSSfYwgYV4BX4kDe+8zQsx/xyKx/sct sHpOASeJ27c2gs1kBLro+6k1YDOZBcQlbj2ZD3W1gMSSPeeZIWxRiZeP/7FC2EoSk5aeY4Wo 15FYsPsTG4StLbFs4WtmiMWCEidnPmGZwCg6C8nYWUhaZiFpmYWkZQEjyypGjtLi1LLcdCOD TYzAaDgmwaa7g3HPS8tDjNIcLErivF/eOgcJCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYAz+ EGJV8/PRIdcVz+cvnFpbyHyPxV9XtoMhQOdOdP68KVOPWm6etezQryd2uU9ecwoIu89/U7NC mfnfrNSuggytkL1F0lE1c07tdWV9oftm1slT8qafl1+QVVkYlrZO+ITP3+DDzZKzLyluu+Od fWBeUviW/dK3rfj8EhhtHIzmdFX1vJ2uqaXEUpyRaKjFXFScCACgFZvIVAIAAA== Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 00:07:18 -0000 Don't worry. Just send another BoRR. The rules in the draft work. The sender rewinds to send all again, the receiver marks all stale again. Thanks, Jakob. -----Original Message----- From: Chris Hall [mailto:chris.hall@highwayman.com]=20 Sent: Thursday, January 23, 2014 2:30 PM OK... given that RRQ has no effect on state, it doesn't matter if the far e= nd is psychic, and sends BoRR before it sees the RRQ :-) =20 From enkechen@cisco.com Thu Jan 23 17:19:44 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A51821A015F for ; Thu, 23 Jan 2014 17:19:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.035 X-Spam-Level: X-Spam-Status: No, score=-15.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGScSw0k7vdl for ; Thu, 23 Jan 2014 17:19:42 -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 48E1B1A010E for ; Thu, 23 Jan 2014 17:19:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13695; q=dns/txt; s=iport; t=1390526381; x=1391735981; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=IgP+IxYCs7CISJQsnTzngYDtN0mrJkO7FT/Ah52WVrQ=; b=fF/x+mwt2D4PUSwAdgWn5k5DLnXedo1jeCwX3mPWUUkdFlqJYMoZFlDu JE8w9rlwhiapBWaY7Tqd5lBrSkMW7STUJso6V4hUe0CUHswruI5FpJ4/f /tC6GuwRByw+nd5BYBoIaeIdH7J5BX0G494u0VeRZ2c35LjECKjyR783J 0=; X-IronPort-AV: E=Sophos;i="4.95,709,1384300800"; d="scan'208,217";a="101204134" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 24 Jan 2014 01:19:41 +0000 Received: from [128.107.150.114] (dhcp-128-107-150-114.cisco.com [128.107.150.114]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0O1JfOw005436; Fri, 24 Jan 2014 01:19:41 GMT Message-ID: <52E1BFAD.8040900@cisco.com> Date: Thu, 23 Jan 2014 17:19:41 -0800 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Susan Hares , idr wg References: <026801cf0d04$af4998a0$0ddcc9e0$@ndzh.com>, In-Reply-To: Content-Type: multipart/alternative; boundary="------------040300040702070600060305" Cc: "'John G. Scudder'" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 01:19:44 -0000 This is a multi-part message in MIME format. --------------040300040702070600060305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit As a co-author, I am not aware of any IPR related to the draft either. Thanks. -- Enke On 1/21/14 10:05 PM, Balaji Pitta venkatachalapathy wrote: > As co-author, I am not aware of any IPR related to the draft. > > Thanks > Balaji > > From: Susan Hares > > Date: Wednesday, January 8, 2014 10:33 PM > To: idr wg > > Cc: "'John G. Scudder'" > > Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh > > Correcting the header. > > Sue > > *From:*Susan Hares [mailto:shares@ndzh.com] > *Sent:* Thursday, January 09, 2014 1:25 AM > *To:* idr wg (idr@ietf.org ) > *Cc:* 'John G. Scudder'; John G. Scudder (jgs@juniper.net > ) > *Subject:* WG LC for > > This is a 2 week WG LC for IPR on the following draft: > > Enhanced Route Refresh Capability for BGP-4 > > draft-ietf-idr-bgp-enhanced-route-refresh-05.txt > > The 2 week WG LC starts on 1/9/14 and ends on 1/22/14. > > The questions are as follows: > > 1)Do the co-authors or any WG participant know of any IPR on this draft? > > 2)Do you support the draft-ietf-idr-bgp-enhanced-route-refresh-05.txt > > For publishing as an RFC? > > Sample answer: > > 1)IPR: I do/I do not know of IPR for this draft > > 2)RFC: Support > > Comments are always welcome. > > Sue and John > > WG chairs > > > _______________________________________________ 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 --------------040300040702070600060305 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
As a co-author, I am not aware of any IPR related to the draft either.

Thanks.   -- Enke

On 1/21/14 10:05 PM, Balaji Pitta venkatachalapathy wrote:
As co-author, I am not aware of any IPR related to the draft.

Thanks
Balaji

From: Susan Hares <shares@ndzh.com>
Date: Wednesday, January 8, 2014 10:33 PM
To: idr wg <idr@ietf.org>
Cc: "'John G. Scudder'" <jgs@bgp.nu>
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Correcting the header.

Sue

 

From: Susan Hares [mailto:shares@ndzh.com]
Sent: Thursday, January 09, 2014 1:25 AM
To: idr wg (idr@ietf.org)
Cc: 'John G. Scudder'; John G. Scudder (jgs@juniper.net)
Subject: WG LC for

 

This is a 2 week WG LC for IPR on the following draft:

 

Enhanced Route Refresh Capability for BGP-4

draft-ietf-idr-bgp-enhanced-route-refresh-05.txt

 

The 2 week WG LC starts on 1/9/14 and ends on 1/22/14.

 

The questions are as follows:

 

1)  Do the co-authors or any WG participant know of any IPR on this draft?

2)  Do you support the draft-ietf-idr-bgp-enhanced-route-refresh-05.txt

For publishing as an RFC?

 

Sample answer:

1)  IPR: I do/I do not know of IPR for this draft  

2)  RFC: Support

 

 

Comments are always welcome.

 

Sue and John

WG chairs

 

 

 
_______________________________________________ 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

--------------040300040702070600060305-- From shares@ndzh.com Thu Jan 23 20:52:13 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C221A00F1 for ; Thu, 23 Jan 2014 20:52:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JTo1L5T6R_r for ; Thu, 23 Jan 2014 20:52:11 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 371941A0094 for ; Thu, 23 Jan 2014 20:52:11 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: References: <76CD132C3ADEF848BD84D028D243C927335BF625@nkgeml512-mbx.china.huawei.com> In-Reply-To: Date: Thu, 23 Jan 2014 23:52:09 -0500 Message-ID: <00ba01cf18c0$0a023ce0$1e06b6a0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BB_01CF1896.212F9040" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJh04Rm7poB0aIUIcMZNAVmaKxw65lt2BLg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: draft-dong-idr-te-lsp-distribution@tools.ietf.org Subject: Re: [Idr] Appreciate your opinion on this WG adoption poll\\FW: WG Adoption call for draft-dong-idr-te-lsp-distribution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 04:52:13 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00BB_01CF1896.212F9040 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This working group call for adoption has completed. The WG has accepted this draft: draft-dong-idr-te-lsp-distribution-04 https://datatracker.ietf.org/doc/draft-dong-idr-te-lsp-distribution/ Will the authors please submit this as: draft-idr-te-lsp-distribution Sue Hares Co-chair From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Thursday, January 09, 2014 6:35 PM To: idr wg Cc: draft-dong-idr-te-lsp-distribution@tools.ietf.org Subject: [Idr] WG Adoption call for draft-dong-idr-te-lsp-distribution IDR WG: This is to give a 2 week Call for adoption of: Distribution of MPLS Traffic Engineering (TE) LSP State using BGP draft-dong-idr-te-lsp-distribution-04 https://datatracker.ietf.org/doc/draft-dong-idr-te-lsp-distribution/ WG 2 week calls begins 1/9/14 and ends 1/22/14 Technical description: This document describes a mechanism to collect the Traffic Engineering (TE) LSP information using BGP. Such information can be used by external components for path re-optimization, service placement and network visualization. Sue and John IDR co-chairs ------=_NextPart_000_00BB_01CF1896.212F9040 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

This working group call for adoption has = completed.  The WG has accepted this draft:

=

draft-dong-idr-te-lsp-distri= bution-04

https://datatracker.ietf.org/doc/draft-dong-idr-te-lsp-distribution/=

 

=

Will the authors please = submit this as:

 

=

draft-idr-te-lsp-distributio= n

 

=

Sue = Hares

Co-chair =

From: Idr [mailto:idr-bounces@ietf.org] = On Behalf Of Susan Hares
Sent: Thursday, January 09, = 2014 6:35 PM
To: idr wg
Cc: draft-d= ong-idr-te-lsp-distribution@tools.ietf.org
Subject: [Idr] = WG Adoption call for draft-dong-idr-te-lsp-distribution=

 =

IDR WG:

 

This is to give a 2 week = Call for adoption of:

 

Distribution of MPLS = Traffic Engineering (TE) LSP State using BGP

draft-dong-idr-te-lsp-distri= bution-04

 

https://datatracker.ietf.org/doc/draft-dong-idr-te-lsp-distribution/=

 

WG 2 week calls begins = 1/9/14 and ends 1/22/14

 

Technical description: =

This document describes a = mechanism to collect the Traffic Engineering (TE) LSP information using = BGP.  Such information can be used by external components for path = re-optimization, service placement and network = visualization.

 

 

Sue and John

IDR co-chairs

 

------=_NextPart_000_00BB_01CF1896.212F9040-- From internet-drafts@ietf.org Fri Jan 24 07:05:52 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE3101A04BD; Fri, 24 Jan 2014 07:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZeKZOJRWDc8; Fri, 24 Jan 2014 07:05:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A05A21A01BC; Fri, 24 Jan 2014 07:05:50 -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: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140124150550.3301.84527.idtracker@ietfa.amsl.com> Date: Fri, 24 Jan 2014 07:05:50 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-te-lsp-distribution-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 15:05:52 -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 : Distribution of MPLS Traffic Engineering (TE) LSP= State using BGP Authors : Jie Dong Mach(Guoyi) Chen Hannes Gredler Stefano Previdi Filename : draft-ietf-idr-te-lsp-distribution-00.txt Pages : 8 Date : 2014-01-24 Abstract: This document describes a mechanism to collect the Traffic Engineering (TE) LSP information using BGP. Such information can be used by external components for path reoptimization, service placement and network visualization. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-te-lsp-distribution/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-te-lsp-distribution-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From chris.hall@highwayman.com Fri Jan 24 12:00:49 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0CCA1A00E6 for ; Fri, 24 Jan 2014 12:00:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.16 X-Spam-Level: X-Spam-Status: No, score=0.16 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSlCw38BqGoN for ; Fri, 24 Jan 2014 12:00:48 -0800 (PST) Received: from smtp.demon.co.uk (mdfmta005.mxout.tbr.inty.net [91.221.168.46]) by ietfa.amsl.com (Postfix) with ESMTP id 80F271A0529 for ; Fri, 24 Jan 2014 12:00:36 -0800 (PST) Received: from mdfmta005.tbr.inty.net (unknown [127.0.0.1]) by mdfmta005.tbr.inty.net (Postfix) with ESMTP id 20ED1A64C51; Fri, 24 Jan 2014 20:00:34 +0000 (GMT) Received: from mdfmta005.tbr.inty.net (unknown [127.0.0.1]) by mdfmta005.tbr.inty.net (Postfix) with ESMTP id F0868A64C2A; Fri, 24 Jan 2014 20:00:33 +0000 (GMT) Received: from hestia.halldom.com (unknown [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta005.tbr.inty.net (Postfix) with ESMTP; Fri, 24 Jan 2014 20:00:33 +0000 (GMT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by hestia.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1W6mvZ-00076m-2X; Fri, 24 Jan 2014 20:00:33 +0000 From: "Chris Hall" To: References: <13E5680B-7295-4C05-B913-C5339993FA32@highwayman.com> In-Reply-To: Date: Fri, 24 Jan 2014 20:00:27 -0000 Organization: Highwayman Message-ID: <084c01cf193e$f07d3d40$d177b7c0$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQG9zgs92koa44y7VzKFNSEUGi4weJq2V4jg Content-Language: en-gb X-MDF-HostID: 8 Cc: "'Keyur Patel \(keyupate\)'" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 20:00:50 -0000 Keyur Patel wrote (on Thu 23-Jan-2014 at 23:54 +0000): ... > >I remain puzzled as to the need for EoRR. > > > >Chris > As per RFC4724, EOR is signaled to indicate exchange of initial > Routing table updates. > > Amongst other things (as you indicated), implementations are > required to defer route selection process till EOR is received. > > EORR on other hand indicates exchange of subsequent Routing table > updates. > > Both of them are enabled using different capabilities. > > We believe they have different semantics and wanted to avoid > overloading EOR. So, the "initial update" (per RFC4724), graceful or otherwise, is intended to be orthogonal to route-refresh triggered by either route-refresh request (RRQ) or BoRR. Hence, any route-refresh during the "initial update" (however bonkers) would be treated as being nested inside that initial update -- so start and end before the EoR. The straightforward approach to BoRR during "initial update" is for the sender (of the BoRR) to rewind and then keep going until it has sent everything there is to send. The EoRR and EoR are then triggered simultaneously but sent in that order. The receiver of the BoRR (re-)marks everything stale (not flushing existing stale and not restarting any stale-timer, presumably) and proceeds until it sees EoRR and then EoR (and, possibly, further BoRR before the EoRR). This approach implicitly uses the same stale marking and flushing, and the same stale-timer as (any) Graceful Restart -- making the EoRR, largely, redundant in this state. One could argue that, during initial update, after a BoRR the sender could/should only repeat the routes which have been sent up to that point, and then issue the EoRR. The initial update would then proceed from where it left off. This is fully consistent with treating "initial update" and route-refresh as orthogonal, but complicates things, to no obvious advantage. If such a "clever" approach were deemed to be a useful implementation option, the specification needs to provide for the combinations of "clever" and "straightforward" senders and receivers. It seems to me that initial update interacts with enhanced route-refresh, so they aren't entirely orthogonal, and the interaction could do with being defined. Yet another option would be to ban BoRR in initial update state, or define it to implicitly terminate that state (BoRR => EoR) (it's not clear to me how useful BoRR is in initial update state). And, Enhanced Route-Refresh could be suppressed in initial update state, so that RRQ operates as now (for what that's worth). These steps eliminate the whole BoRR/EoRR during initial update kerfuffle altogether. Finally, perhaps the conclusion is that during initial update, BoRR really means "I am restarting the initial update"... and perhaps BoRR should not be overloaded here ? Chris PS: I hear what you say, but I cannot help feeling that EoR could be enabled for its current semantics (when in "initial update" state) by the Graceful Restart capability, and enabled for EoRR semantics (when not in "initial update" state) by the Enhanced Route-Refresh capability. There would then be one less message type to worry about :-) And the meaning of the combined EoR/EoRR message is explicitly dependent on the "initial update" state. From enkechen@cisco.com Fri Jan 24 12:11:39 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCA11A00A4 for ; Fri, 24 Jan 2014 12:11:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucVKoQPRVqSg for ; Fri, 24 Jan 2014 12:11: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 95B701A001A for ; Fri, 24 Jan 2014 12:11:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3865; q=dns/txt; s=iport; t=1390594296; x=1391803896; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=cMFpirD9Vo/VUd9Z6su2QuSEudjXC9sa7kP2I0Xjows=; b=kgj+g8LCFFc6VJ2Z72VA98/LH43oMoN9a3dRh6jCduOtG/RhhbGS3FqP gYpzLHZ+eCo7xRtDIPlpIdV/ToAOwBWOngnelVjeFXr8KPWCqAEJSqbOX 0OJAFG3jaKdGyzrAwCWx668cmndaU1Kv3tZ2pukCdal2/2a6Zd+ulwbRt A=; X-IronPort-AV: E=Sophos;i="4.95,714,1384300800"; d="scan'208";a="103787628" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 24 Jan 2014 20:11:36 +0000 Received: from [128.107.150.114] (dhcp-128-107-150-114.cisco.com [128.107.150.114]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0OKBaCj018303; Fri, 24 Jan 2014 20:11:36 GMT Message-ID: <52E2C8F8.1050001@cisco.com> Date: Fri, 24 Jan 2014 12:11:36 -0800 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Chris Hall , idr@ietf.org References: <13E5680B-7295-4C05-B913-C5339993FA32@highwayman.com> <084c01cf193e$f07d3d40$d177b7c0$@highwayman.com> In-Reply-To: <084c01cf193e$f07d3d40$d177b7c0$@highwayman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'Keyur Patel \(keyupate\)'" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 20:11:39 -0000 No overloading of the existing semantics of EOR, please. There have been many lessons from even minimal and innocent deviation of semantics (e.g., using empty UPDATE as EOR). -- Enke On 1/24/14 12:00 PM, Chris Hall wrote: > Keyur Patel wrote (on Thu 23-Jan-2014 at 23:54 +0000): > ... >>> I remain puzzled as to the need for EoRR. >>> >>> Chris >> As per RFC4724, EOR is signaled to indicate exchange of initial >> Routing table updates. >> >> Amongst other things (as you indicated), implementations are >> required to defer route selection process till EOR is received. >> >> EORR on other hand indicates exchange of subsequent Routing table >> updates. >> >> Both of them are enabled using different capabilities. >> >> We believe they have different semantics and wanted to avoid >> overloading EOR. > So, the "initial update" (per RFC4724), graceful or otherwise, is > intended to be orthogonal to route-refresh triggered by either > route-refresh request (RRQ) or BoRR. > > Hence, any route-refresh during the "initial update" (however bonkers) > would be treated as being nested inside that initial update -- so > start and end before the EoR. > > The straightforward approach to BoRR during "initial update" is for > the sender (of the BoRR) to rewind and then keep going until it has > sent everything there is to send. The EoRR and EoR are then triggered > simultaneously but sent in that order. The receiver of the BoRR > (re-)marks everything stale (not flushing existing stale and not > restarting any stale-timer, presumably) and proceeds until it sees > EoRR and then EoR (and, possibly, further BoRR before the EoRR). This > approach implicitly uses the same stale marking and flushing, and the > same stale-timer as (any) Graceful Restart -- making the EoRR, > largely, redundant in this state. > > One could argue that, during initial update, after a BoRR the sender > could/should only repeat the routes which have been sent up to that > point, and then issue the EoRR. The initial update would then proceed > from where it left off. This is fully consistent with treating > "initial update" and route-refresh as orthogonal, but complicates > things, to no obvious advantage. If such a "clever" approach were > deemed to be a useful implementation option, the specification needs > to provide for the combinations of "clever" and "straightforward" > senders and receivers. > > It seems to me that initial update interacts with enhanced > route-refresh, so they aren't entirely orthogonal, and the interaction > could do with being defined. > > Yet another option would be to ban BoRR in initial update state, or > define it to implicitly terminate that state (BoRR => EoR) (it's not > clear to me how useful BoRR is in initial update state). And, > Enhanced Route-Refresh could be suppressed in initial update state, so > that RRQ operates as now (for what that's worth). These steps > eliminate the whole BoRR/EoRR during initial update kerfuffle > altogether. > > Finally, perhaps the conclusion is that during initial update, BoRR > really means "I am restarting the initial update"... and perhaps BoRR > should not be overloaded here ? > > Chris > > PS: I hear what you say, but I cannot help feeling that EoR could be > enabled for its current semantics (when in "initial update" state) by > the Graceful Restart capability, and enabled for EoRR semantics (when > not in "initial update" state) by the Enhanced Route-Refresh > capability. There would then be one less message type to worry about > :-) And the meaning of the combined EoR/EoRR message is explicitly > dependent on the "initial update" state. > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From jakob.heitz@ericsson.com Fri Jan 24 12:19:33 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 059EA1A0126 for ; Fri, 24 Jan 2014 12:19:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5PLcOcz7Zmf1 for ; Fri, 24 Jan 2014 12:19:26 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 187A31A018C for ; Fri, 24 Jan 2014 12:19:26 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-64-52e2cac938a3 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id C6.57.12743.9CAC2E25; Fri, 24 Jan 2014 21:19:21 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0387.000; Fri, 24 Jan 2014 15:19:24 -0500 From: Jakob Heitz To: Enke Chen , Chris Hall , "idr@ietf.org" Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPF5KdKHMolEg8TF26AxOKep0T6JqRMOhAgAGfMAD//7gu+4AAX1gA//+1BTCAAHhgAP//sQGgAA5+ToAAAu2uAAAqJEuAAABjsAAAClPl4A== Date: Fri, 24 Jan 2014 20:19:23 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F57776@eusaamb109.ericsson.se> References: <13E5680B-7295-4C05-B913-C5339993FA32@highwayman.com> <084c01cf193e$f07d3d40$d177b7c0$@highwayman.com> <52E2C8F8.1050001@cisco.com> In-Reply-To: <52E2C8F8.1050001@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUyuXRPlO7JU4+CDA6tNrN4/2sbs8WSKXfY LV7dfsZk0bj1PJsDi8eU3xtZPY4f3cXssWTJT6YA5igum5TUnMyy1CJ9uwSujJ0TuQp+q1Ss vryFpYGxR66LkZNDQsBE4s3yHkYIW0ziwr31bCC2kMARRolFs1K6GLmA7OWMEgfaXjKBJNgE dCS+Xe9iBrFFBLIlPt3bDNbMLGAs8XXPDlYQW1jATeJuy2cmiBp3iZYfk6Dq6yQeH3sBtICD g0VAVeLoq1yQMK+Ar8Tr7SfYIXZtZ5TY9XM/2BGcApoSm7sPgc1hBDru+6k1TBC7xCVuPZnP BHG0gMSSPeeZIWxRiZeP/7FC2EoSk5aeY4Wo15FYsPsTG4StLbFs4WtmiMWCEidnPmGZwCg2 C8nYWUhaZiFpmYWkZQEjyypGjtLi1LLcdCODTYzACDomwaa7g3HPS8tDjNIcLErivF/eOgcJ CaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYBQ5LDC79pxLV7lvI+vSUpeP+XrHJzBvrlpz9rtr 0v5eY7b6g3vtFsvURAQx3Ym+dCFvpfNmsUM1E9dMLa/Tl7+kFPrq1hvHnCnMHQUqLuumVU6q vfRe7nGB0Nz77effip0s2PE5zavlImO396nk6NPfj64y+fShehvnnkn3fA/fOB3CU36Pp1qJ pTgj0VCLuag4EQBZXdQjbgIAAA== Cc: "'Keyur Patel \(keyupate\)'" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 20:19:33 -0000 Chris, I think the draft, as written, works. It's a bit hard to verify all the cases and as you can see from the email c= hain, I did stumble at one point, but I can see that it all works now. Can you see something that doesn't work? PS. your suggestion of NOT rewinding when sending BoRR before EoR does NOT = work. Thanks, Jakob. -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Enke Chen Sent: Friday, January 24, 2014 12:12 PM To: Chris Hall; idr@ietf.org Cc: 'Keyur Patel (keyupate)' Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh No overloading of the existing semantics of EOR, please. There have been m= any lessons from even minimal and innocent deviation of semantics (e.g., u= sing empty UPDATE as EOR). -- Enke On 1/24/14 12:00 PM, Chris Hall wrote: > Keyur Patel wrote (on Thu 23-Jan-2014 at 23:54 +0000): > ... >>> I remain puzzled as to the need for EoRR. >>> >>> Chris >> As per RFC4724, EOR is signaled to indicate exchange of initial=20 >> Routing table updates. >> >> Amongst other things (as you indicated), implementations are required=20 >> to defer route selection process till EOR is received. >> >> EORR on other hand indicates exchange of subsequent Routing table=20 >> updates. >> >> Both of them are enabled using different capabilities. >> >> We believe they have different semantics and wanted to avoid=20 >> overloading EOR. > So, the "initial update" (per RFC4724), graceful or otherwise, is=20 > intended to be orthogonal to route-refresh triggered by either=20 > route-refresh request (RRQ) or BoRR. > > Hence, any route-refresh during the "initial update" (however bonkers)=20 > would be treated as being nested inside that initial update -- so=20 > start and end before the EoR. > > The straightforward approach to BoRR during "initial update" is for=20 > the sender (of the BoRR) to rewind and then keep going until it has=20 > sent everything there is to send. The EoRR and EoR are then triggered=20 > simultaneously but sent in that order. The receiver of the BoRR=20 > (re-)marks everything stale (not flushing existing stale and not=20 > restarting any stale-timer, presumably) and proceeds until it sees=20 > EoRR and then EoR (and, possibly, further BoRR before the EoRR). This=20 > approach implicitly uses the same stale marking and flushing, and the=20 > same stale-timer as (any) Graceful Restart -- making the EoRR,=20 > largely, redundant in this state. > > One could argue that, during initial update, after a BoRR the sender=20 > could/should only repeat the routes which have been sent up to that=20 > point, and then issue the EoRR. The initial update would then proceed=20 > from where it left off. This is fully consistent with treating=20 > "initial update" and route-refresh as orthogonal, but complicates=20 > things, to no obvious advantage. If such a "clever" approach were=20 > deemed to be a useful implementation option, the specification needs=20 > to provide for the combinations of "clever" and "straightforward" > senders and receivers. > > It seems to me that initial update interacts with enhanced=20 > route-refresh, so they aren't entirely orthogonal, and the interaction=20 > could do with being defined. > > Yet another option would be to ban BoRR in initial update state, or=20 > define it to implicitly terminate that state (BoRR =3D> EoR) (it's not=20 > clear to me how useful BoRR is in initial update state). And,=20 > Enhanced Route-Refresh could be suppressed in initial update state, so=20 > that RRQ operates as now (for what that's worth). These steps=20 > eliminate the whole BoRR/EoRR during initial update kerfuffle=20 > altogether. > > Finally, perhaps the conclusion is that during initial update, BoRR=20 > really means "I am restarting the initial update"... and perhaps BoRR=20 > should not be overloaded here ? > > Chris > > PS: I hear what you say, but I cannot help feeling that EoR could be=20 > enabled for its current semantics (when in "initial update" state) by=20 > the Graceful Restart capability, and enabled for EoRR semantics (when=20 > not in "initial update" state) by the Enhanced Route-Refresh=20 > capability. There would then be one less message type to worry about > :-) And the meaning of the combined EoR/EoRR message is explicitly=20 > dependent on the "initial update" state. > > > _______________________________________________ > 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 chris.hall@highwayman.com Fri Jan 24 12:22:51 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A41C81A01B0 for ; Fri, 24 Jan 2014 12:22:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.16 X-Spam-Level: X-Spam-Status: No, score=0.16 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNwXN-N2T2TQ for ; Fri, 24 Jan 2014 12:22:50 -0800 (PST) Received: from smtp.demon.co.uk (mdfmta009.mxout.tbr.inty.net [91.221.168.50]) by ietfa.amsl.com (Postfix) with ESMTP id E4DE81A01A3 for ; Fri, 24 Jan 2014 12:22:49 -0800 (PST) Received: from mdfmta009.tbr.inty.net (unknown [127.0.0.1]) by mdfmta009.tbr.inty.net (Postfix) with ESMTP id 24ADC384081; Fri, 24 Jan 2014 20:22:48 +0000 (GMT) Received: from mdfmta009.tbr.inty.net (unknown [127.0.0.1]) by mdfmta009.tbr.inty.net (Postfix) with ESMTP id 00494384083; Fri, 24 Jan 2014 20:22:48 +0000 (GMT) Received: from hestia.halldom.com (unknown [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta009.tbr.inty.net (Postfix) with ESMTP; Fri, 24 Jan 2014 20:22:47 +0000 (GMT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by hestia.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1W6nH5-00076q-9U; Fri, 24 Jan 2014 20:22:47 +0000 From: "Chris Hall" To: "'Jakob Heitz'" , References: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F54ED5@eusaamb109.ericsson.se> <10eca092172d443380eccf2e8548f2a9@BLUPR09MB053.namprd09.prod.outlook.com> <98FB84F8-96B2-4D7B-8FF0-0A3DE4D90465@ericsson.com> <07a101cf1861$7cf46700$76dd3500$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F55B8C@eusaamb109.ericsson.se> <07c701cf1878$2f67aee0$8e370ca0$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F55E37@eusaamb109.ericsson.se> <13E5680B-7295-4C05-B913-C5339993FA32@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F56346@eusaamb109.ericsson.se> In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F56346@eusaamb109.ericsson.se> Date: Fri, 24 Jan 2014 20:22:42 -0000 Organization: Highwayman Message-ID: <085301cf1942$0bbdae70$23390b50$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQG//zNq4hUhbREFIybMDiQfLPKfmwIlA/HBAjQliZgBA79uvgEPvMpIAkI1woMBcE7NewKhWRTQAapNyg0CL4/SdwGCKLr4miEBCyA= Content-Language: en-gb X-MDF-HostID: 4 Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 20:22:51 -0000 X-List-Received-Date: Fri, 24 Jan 2014 20:22:51 -0000 Jakob Heitz wrote (on Fri 24-Jan-2014 at 00:07 +0000): ... > Don't worry. Just send another BoRR. > The rules in the draft work. > The sender rewinds to send all again, the receiver marks all stale > again. Graceful Restart is, of course, a separate topic -- but the Receiving Speaker action is similar to the response to BoRR, and begs comparison. What's more, GR and Enhanced Route-Refresh interact. In GR, the process of marking routes stale (currently) requires any existing stale to be immediately flushed. The draft is silent on whether BoRR flushes old stale or restarts any existing stale-timer, whether set by GR or BoRR or otherwise -- perhaps these are intended to be implementation decisions ? I observe that, by rule, EoRR is sent when all routes have been sent. Hence, EoRR is a terminator (BoRR and EoRR are not brackets). And the effect of BoRR is context independent. So, as you say, the rules cope with: A) send: RRQ recv: BoRR u1 u2 BoRR u1 u2 u3 ... EoRR B) recv: RRQ send: BoRR u1 u2 BoRR u1 u2 u3 ... EoRR [where time runs left to right, and this is intended to show the conversation from the perspective of the two parties 'A' and 'B'.] The receiver of the BoRR ('A') can (apparently) decide whether to flush stale and/or restart its stale-timer on receipt of the second BoRR -- for my money: I would not flush stale and I would not restart the stale-timer. In the case shown, rewinding and starting again with the second BoRR is a sad waste of effort. But the case is indistinguishable from: A) send: RRQ recv: BoRR u1 u2 BoRR u1 u2 u3 ... EoRR B) recv: RRQ send: BoRR u1 u2 BoRR u1 u2 u3 ... EoRR as far as 'B' is concerned. But these are extreme-fringe cases... so tant pis. FWIW, other bonkers cases which "just work" include: A) send: RRQ recv: BoRR u1 u2 EoRR BoRR u1 u2 EoRR B) recv: RRQ send: BoRR u1 u2 EoRR BoRR u1 u2 EoRR and: A) send: RRQ recv: BoRR u1 u2 EoRR BoRR u1 u2 EoRR B) recv: RRQ send: BoRR u1 u2 EoRR BoRR u1 u2 EoRR Chris From jakob.heitz@ericsson.com Fri Jan 24 12:37:20 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A731A004E for ; Fri, 24 Jan 2014 12:37:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvY7NYWIGwI3 for ; Fri, 24 Jan 2014 12:37:18 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id B74F81A01B8 for ; Fri, 24 Jan 2014 12:37:15 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-07-52e2cefa14ae Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 6E.D9.11484.AFEC2E25; Fri, 24 Jan 2014 21:37:15 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0387.000; Fri, 24 Jan 2014 15:37:13 -0500 From: Jakob Heitz To: Chris Hall , "idr@ietf.org" Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPF5KdKHMolEg8TF26AxOKep0T6JqRMOhAgAGfMAD//7gu+4AAX1gA//+1BTCAAHhgAP//sQGgAA5+ToAABygAoAAmsOcAAAoIr7A= Date: Fri, 24 Jan 2014 20:37:13 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F577F9@eusaamb109.ericsson.se> References: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F54ED5@eusaamb109.ericsson.se> <10eca092172d443380eccf2e8548f2a9@BLUPR09MB053.namprd09.prod.outlook.com> <98FB84F8-96B2-4D7B-8FF0-0A3DE4D90465@ericsson.com> <07a101cf1861$7cf46700$76dd3500$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F55B8C@eusaamb109.ericsson.se> <07c701cf1878$2f67aee0$8e370ca0$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F55E37@eusaamb109.ericsson.se> <13E5680B-7295-4C05-B913-C5339993FA32@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F56346@eusaamb109.ericsson.se> <085301cf1942$0bbdae70$23390b50$@highwayman.com> In-Reply-To: <085301cf1942$0bbdae70$23390b50$@highwayman.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsUyuXRPoO7vc4+CDGbdZ7Z4/2sbs8Wr28+Y HJg8jh/dxeyxZMlPpgCmKC6blNSczLLUIn27BK6Mo0s+MBY8YK4403iBvYGxhbmLkZNDQsBE Yk7XBXYIW0ziwr31bF2MXBxCAkcYJfbe3sMM4SxnlLj+u4MJpIpNQEfi2/UusG4RAU+Jl++u sIDYwgJuEndbPjNBxN0lWn5Mgqopk1jxdBUriM0ioCqx+vVNsBpeAV+JKz/vMkIseMoq8eft Q6AEBwengK1Ex/sskBpGoIu+n1oDVs8sIC5x68l8JohLBSSW7DkP9YGoxMvH/1ghbCWJSUvP sULU60gs2P2JDcLWlli28DUzxF5BiZMzn7BMYBSdhWTsLCQts5C0zELSsoCRZRUjR2lxallu upHhJkZgPByTYHPcwbjgk+UhRmkOFiVx3i9vnYOEBNITS1KzU1MLUovii0pzUosPMTJxcEo1 ME5mUL3PIfe1/cm5q96JNfYvxZRt9b/pdPdainQ1rm84U+z/5OXxD5MnT+/+sUH8xZHsa5O9 flsY7TAzDj4umbf4U2+oscaH13VNLefWblLhfBL2dN5Jkc74AmejSO1eod9/G+x6q6rfdTXx 7OmL6li3flmA7GO3MBmjhPUNRiZzPtzp1HrbrcRSnJFoqMVcVJwIAFjUbodVAgAA Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 20:37:20 -0000 Silence means don't do it. You would definitely NOT want BoRR to flush old stales. Restarting the timer might be a good idea. Thanks, Jakob. -----Original Message----- From: Chris Hall [mailto:chris.hall@highwayman.com]=20 Sent: Friday, January 24, 2014 12:23 PM The draft is silent on whether BoRR flushes old stale or restarts any exist= ing stale-timer, whether set by GR or BoRR or otherwise -- perhaps these ar= e intended to be implementation decisions ? From shares@ndzh.com Fri Jan 24 12:45:51 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1CA1A01C8 for ; Fri, 24 Jan 2014 12:45:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRdYy4a-UcEB for ; Fri, 24 Jan 2014 12:45:49 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 46DF41A0206 for ; Fri, 24 Jan 2014 12:45:36 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Jakob Heitz'" , "'Enke Chen'" , "'Chris Hall'" , References: <13E5680B-7295-4C05-B913-C5339993FA32@highwayman.com> <084c01cf193e$f07d3d40$d177b7c0$@highwayman.com> <52E2C8F8.1050001@cisco.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F57776@eusaamb109.ericsson.se> In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F57776@eusaamb109.ericsson.se> Date: Fri, 24 Jan 2014 15:45:26 -0500 Message-ID: <004501cf1945$368ecdc0$a3ac6940$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIvj9J3oLl6dQqzCBE8T6a0E/4e0gG9zgs9AeFL4BgBkmhjEwH/W3VumZnjb+A= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: "'Keyur Patel \(keyupate\)'" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 20:45:52 -0000 Chris: [IDR co-chair hat is on] It would be good to answer Jakob's question as we have a deployed implementations of this protocol? Are the problems that the implementers should know about? [IDR co-chair hat off] Sue Hares -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz Sent: Friday, January 24, 2014 3:19 PM To: Enke Chen; Chris Hall; idr@ietf.org Cc: 'Keyur Patel (keyupate)' Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Chris, I think the draft, as written, works. It's a bit hard to verify all the cases and as you can see from the email chain, I did stumble at one point, but I can see that it all works now. Can you see something that doesn't work? PS. your suggestion of NOT rewinding when sending BoRR before EoR does NOT work. Thanks, Jakob. -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Enke Chen Sent: Friday, January 24, 2014 12:12 PM To: Chris Hall; idr@ietf.org Cc: 'Keyur Patel (keyupate)' Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh No overloading of the existing semantics of EOR, please. There have been many lessons from even minimal and innocent deviation of semantics (e.g., using empty UPDATE as EOR). -- Enke On 1/24/14 12:00 PM, Chris Hall wrote: > Keyur Patel wrote (on Thu 23-Jan-2014 at 23:54 +0000): > ... >>> I remain puzzled as to the need for EoRR. >>> >>> Chris >> As per RFC4724, EOR is signaled to indicate exchange of initial >> Routing table updates. >> >> Amongst other things (as you indicated), implementations are required >> to defer route selection process till EOR is received. >> >> EORR on other hand indicates exchange of subsequent Routing table >> updates. >> >> Both of them are enabled using different capabilities. >> >> We believe they have different semantics and wanted to avoid >> overloading EOR. > So, the "initial update" (per RFC4724), graceful or otherwise, is > intended to be orthogonal to route-refresh triggered by either > route-refresh request (RRQ) or BoRR. > > Hence, any route-refresh during the "initial update" (however bonkers) > would be treated as being nested inside that initial update -- so > start and end before the EoR. > > The straightforward approach to BoRR during "initial update" is for > the sender (of the BoRR) to rewind and then keep going until it has > sent everything there is to send. The EoRR and EoR are then triggered > simultaneously but sent in that order. The receiver of the BoRR > (re-)marks everything stale (not flushing existing stale and not > restarting any stale-timer, presumably) and proceeds until it sees > EoRR and then EoR (and, possibly, further BoRR before the EoRR). This > approach implicitly uses the same stale marking and flushing, and the > same stale-timer as (any) Graceful Restart -- making the EoRR, > largely, redundant in this state. > > One could argue that, during initial update, after a BoRR the sender > could/should only repeat the routes which have been sent up to that > point, and then issue the EoRR. The initial update would then proceed > from where it left off. This is fully consistent with treating > "initial update" and route-refresh as orthogonal, but complicates > things, to no obvious advantage. If such a "clever" approach were > deemed to be a useful implementation option, the specification needs > to provide for the combinations of "clever" and "straightforward" > senders and receivers. > > It seems to me that initial update interacts with enhanced > route-refresh, so they aren't entirely orthogonal, and the interaction > could do with being defined. > > Yet another option would be to ban BoRR in initial update state, or > define it to implicitly terminate that state (BoRR => EoR) (it's not > clear to me how useful BoRR is in initial update state). And, > Enhanced Route-Refresh could be suppressed in initial update state, so > that RRQ operates as now (for what that's worth). These steps > eliminate the whole BoRR/EoRR during initial update kerfuffle > altogether. > > Finally, perhaps the conclusion is that during initial update, BoRR > really means "I am restarting the initial update"... and perhaps BoRR > should not be overloaded here ? > > Chris > > PS: I hear what you say, but I cannot help feeling that EoR could be > enabled for its current semantics (when in "initial update" state) by > the Graceful Restart capability, and enabled for EoRR semantics (when > not in "initial update" state) by the Enhanced Route-Refresh > capability. There would then be one less message type to worry about > :-) And the meaning of the combined EoR/EoRR message is explicitly > dependent on the "initial update" state. > > > _______________________________________________ > 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 chris.hall@highwayman.com Fri Jan 24 12:58:52 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9432A1A011B for ; Fri, 24 Jan 2014 12:58:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.16 X-Spam-Level: X-Spam-Status: No, score=0.16 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPoE4171rObn for ; Fri, 24 Jan 2014 12:58:50 -0800 (PST) Received: from smtp.demon.co.uk (mdfmta004.mxout.tbr.inty.net [91.221.168.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2BA1A0099 for ; Fri, 24 Jan 2014 12:58:50 -0800 (PST) Received: from mdfmta004.tbr.inty.net (unknown [127.0.0.1]) by mdfmta004.tbr.inty.net (Postfix) with ESMTP id 7C6B0A0C087; Fri, 24 Jan 2014 20:58:48 +0000 (GMT) Received: from mdfmta004.tbr.inty.net (unknown [127.0.0.1]) by mdfmta004.tbr.inty.net (Postfix) with ESMTP id 53320A0C085; Fri, 24 Jan 2014 20:58:48 +0000 (GMT) Received: from hestia.halldom.com (unknown [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta004.tbr.inty.net (Postfix) with ESMTP; Fri, 24 Jan 2014 20:58:47 +0000 (GMT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by hestia.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1W6npv-00076w-7F; Fri, 24 Jan 2014 20:58:47 +0000 From: "Chris Hall" To: References: <13E5680B-7295-4C05-B913-C5339993FA32@highwayman.com> <084c01cf193e$f07d3d40$d177b7c0$@highwayman.com> <52E2C8F8.1050001@cisco.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F57776@eusaamb109.ericsson.se> In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F57776@eusaamb109.ericsson.se> Date: Fri, 24 Jan 2014 20:58:41 -0000 Organization: Highwayman Message-ID: <085a01cf1947$132f67c0$398e3740$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIvj9J3oLl6dQqzCBE8T6a0E/4e0gG9zgs9AeFL4BgBkmhjEwH/W3VumZndm7A= Content-Language: en-gb X-MDF-HostID: 9 Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 20:58:52 -0000 Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:19 +0000): .... > I think the draft, as written, works. > It's a bit hard to verify all the cases and as you can see from the > email chain, I did stumble at one point, > but I can see that it all works now. > > Can you see something that doesn't work? It depends on how many assumptions are made about the interaction with GR and the initial update phase -- ie up to the EoR. If it is assumed that: * the stale marking, flushing and (any) stale-timer are shared between Enhanced Route-Refresh and Graceful Restart. * and BoRR does not flush existing stale (particularly existing GR stale). * and the BoRR either does not restart any existing stale-timer, or this is explicitly an implementation decision. * and following BoRR the sender does proceed to send everything -- so, effectively restarts and then completes the initial update. Because otherwise the EoRR is going to flush stale before the initial update is complete. * and EoRR is sent before EoR -- so EoRR terminates BoRR and then EoR terminates initial update. then (AFAICS) things do indeed work. The EoRR is not very useful, but does no harm -- provided it immediately precedes the EoR (which it should do). [Not flushing stale on EoRR in initial update state avoids the issue. Not sending EoRR at all in initial update state also avoids the issue.] I would agree that these assumptions are not deeply controversial. But I would rather this were a matter of definition and not assumption. > PS. your suggestion of NOT rewinding when sending BoRR before EoR > does NOT work. I didn't intend suggesting such a thing :-( Chris > Thanks, > Jakob. > > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Enke Chen > Sent: Friday, January 24, 2014 12:12 PM > To: Chris Hall; idr@ietf.org > Cc: 'Keyur Patel (keyupate)' > Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route- > refresh > > No overloading of the existing semantics of EOR, please. There > have been many lessons from even minimal and innocent deviation of > semantics (e.g., using empty UPDATE as EOR). > > -- Enke > > On 1/24/14 12:00 PM, Chris Hall wrote: > > Keyur Patel wrote (on Thu 23-Jan-2014 at 23:54 +0000): > > ... > >>> I remain puzzled as to the need for EoRR. > >>> > >>> Chris > >> As per RFC4724, EOR is signaled to indicate exchange of initial > >> Routing table updates. > >> > >> Amongst other things (as you indicated), implementations are > required > >> to defer route selection process till EOR is received. > >> > >> EORR on other hand indicates exchange of subsequent Routing > table > >> updates. > >> > >> Both of them are enabled using different capabilities. > >> > >> We believe they have different semantics and wanted to avoid > >> overloading EOR. > > So, the "initial update" (per RFC4724), graceful or otherwise, is > > intended to be orthogonal to route-refresh triggered by either > > route-refresh request (RRQ) or BoRR. > > > > Hence, any route-refresh during the "initial update" (however > bonkers) > > would be treated as being nested inside that initial update -- so > > start and end before the EoR. > > > > The straightforward approach to BoRR during "initial update" is > for > > the sender (of the BoRR) to rewind and then keep going until it > has > > sent everything there is to send. The EoRR and EoR are then > triggered > > simultaneously but sent in that order. The receiver of the BoRR > > (re-)marks everything stale (not flushing existing stale and not > > restarting any stale-timer, presumably) and proceeds until it > sees > > EoRR and then EoR (and, possibly, further BoRR before the EoRR). > This > > approach implicitly uses the same stale marking and flushing, and > the > > same stale-timer as (any) Graceful Restart -- making the EoRR, > > largely, redundant in this state. > > > > One could argue that, during initial update, after a BoRR the > sender > > could/should only repeat the routes which have been sent up to > that > > point, and then issue the EoRR. The initial update would then > proceed > > from where it left off. This is fully consistent with treating > > "initial update" and route-refresh as orthogonal, but complicates > > things, to no obvious advantage. If such a "clever" approach > were > > deemed to be a useful implementation option, the specification > needs > > to provide for the combinations of "clever" and "straightforward" > > senders and receivers. > > > > It seems to me that initial update interacts with enhanced > > route-refresh, so they aren't entirely orthogonal, and the > interaction > > could do with being defined. > > > > Yet another option would be to ban BoRR in initial update state, > or > > define it to implicitly terminate that state (BoRR => EoR) (it's > not > > clear to me how useful BoRR is in initial update state). And, > > Enhanced Route-Refresh could be suppressed in initial update > state, so > > that RRQ operates as now (for what that's worth). These steps > > eliminate the whole BoRR/EoRR during initial update kerfuffle > > altogether. > > > > Finally, perhaps the conclusion is that during initial update, > BoRR > > really means "I am restarting the initial update"... and perhaps > BoRR > > should not be overloaded here ? > > > > Chris > > > > PS: I hear what you say, but I cannot help feeling that EoR could > be > > enabled for its current semantics (when in "initial update" > state) by > > the Graceful Restart capability, and enabled for EoRR semantics > (when > > not in "initial update" state) by the Enhanced Route-Refresh > > capability. There would then be one less message type to worry > about > > :-) And the meaning of the combined EoR/EoRR message is > explicitly > > dependent on the "initial update" state. > > > > > > _______________________________________________ > > 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 chris.hall@highwayman.com Sat Jan 25 11:28:06 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F431A005B for ; Sat, 25 Jan 2014 11:28:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.16 X-Spam-Level: X-Spam-Status: No, score=0.16 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5FZ2O4jBuR8 for ; Sat, 25 Jan 2014 11:28:04 -0800 (PST) Received: from smtp.demon.co.uk (mdfmta005.mxout.tch.inty.net [91.221.169.46]) by ietfa.amsl.com (Postfix) with ESMTP id 0041B1A002F for ; Sat, 25 Jan 2014 11:28:03 -0800 (PST) Received: from mdfmta005.tch.inty.net (unknown [127.0.0.1]) by mdfmta005.tch.inty.net (Postfix) with ESMTP id AD5CF18CC67; Sat, 25 Jan 2014 19:28:01 +0000 (GMT) Received: from mdfmta005.tch.inty.net (unknown [127.0.0.1]) by mdfmta005.tch.inty.net (Postfix) with ESMTP id 80D0E18CC5D; Sat, 25 Jan 2014 19:28:01 +0000 (GMT) Received: from hestia.halldom.com (unknown [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta005.tch.inty.net (Postfix) with ESMTP; Sat, 25 Jan 2014 19:28:01 +0000 (GMT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by hestia.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1W78tc-00078j-9C; Sat, 25 Jan 2014 19:28:00 +0000 From: "Chris Hall" To: References: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F54ED5@eusaamb109.ericsson.se> <10eca092172d443380eccf2e8548f2a9@BLUPR09MB053.namprd09.prod.outlook.com> <98FB84F8-96B2-4D7B-8FF0-0A3DE4D90465@ericsson.com> <07a101cf1861$7cf46700$76dd3500$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F55B8C@eusaamb109.ericsson.se> <07c701cf1878$2f67aee0$8e370ca0$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F55E37@eusaamb109.ericsson.se> <13E5680B-7295-4C05-B913-C5339993FA32@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F56346@eusaamb109.ericsson.se> <085301cf1942$0bbdae70$23390b50$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F577F9@eusaamb109.ericsson.se> In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F577F9@eusaamb109.ericsson.se> Date: Sat, 25 Jan 2014 19:27:54 -0000 Organization: Highwayman Message-ID: <08e201cf1a03$8efad120$acf07360$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQG//zNq4hUhbREFIybMDiQfLPKfmwIlA/HBAjQliZgBA79uvgEPvMpIAkI1woMBcE7NewKhWRTQAapNyg0CL4/SdwGCKLr4AkOZEXwC+SCNCZn3x+4w Content-Language: en-gb X-MDF-HostID: 18 Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 19:28:06 -0000 Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): ... > Silence means don't do it. Hmmm.... as a principle I'm more comfortable with "that which isn't prohibited is permitted".... > You would definitely NOT want BoRR to flush old stales. ....but, given the definite requirement, and given that the current precedent for "marking stale" does flush old stale, then a few words for the avoidance of doubt ? > Restarting the timer might be a good idea. I dunno... a route which remains stale for "a long time" is, of course, a candidate for being withdrawn: so having started a timer the first time things are set stale, I would avoid extending that -- at least for Graceful Restart, where the whole withdraw thing has been "on-hold" since the last session failed. For route-refresh I guess there's more of a presumption that stale routes will be refreshed sooner or later, and in the meantime they remain good. So if the route-refresh is (repeatedly) restarted for some reason, perhaps it is more reasonable to extend the flush deadline -- but avoid doing this indefinitely ? FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I have built in Quagga prioritise route changes (pending changes and any that occur during the refresh) over refresh updates. This makes it more likely that remaining stale routes are still good. But the other end cannot know that. The paragraph in the draft discussing the "entire Adj-RIB-Out" defines that to be the entries present "at the start of the route refresh operation", and observes that these comprise both reachable and unreachable routes. [An "of" after "comprise" sets teeth on edge, BTW.] I'm really not sure what this paragraph is trying to tell me. The reference to unreachable routes appears to suggest that pending withdraws should be sent as part of the refresh -- so not left to the EoRR to implement at the end. The point at which the EoRR is sent is defined such that it excludes any Adj-RIB-Out entries added after the route-refresh started, but includes any which are changed during the process. It seems reasonable to delay any brand new reachable prefixes until after all previously announced ones have been refreshed and the EoRR sent -- if that's the intent here. Changes which occur before the refresh gets to a given entry are pretty naturally swept up by the refresh. Changes which occur after the refresh has gone past, could/should be deferred to after the EoRR ? Does it make a difference if the change is a withdraw ? (Of course MRAI may kick in here. Ah. MRAI and route-refresh, there's a topic !) I think the essence of the rule is that the EoRR should be sent once all prefixes previously advertised to the peer as reachable have been refreshed, ie announced or withdrawn (at least) once. Or, perhaps more strictly, not *before* those prefixes have *all* been announced once -- given that the EoRR will promptly bang un-advertised stuff on the head. Even more strictly perhaps: not send EoRR *before* any withdraws implied by it are required or desirable. Depending on the implementation, a given sender may or may not be able to determine the minimum set of updates required before sending EoRR. If the refresh operation takes a long time, there may be good routeing reasons to arrange for some route changes to be sent to the peer "early" -- that is to send announcements which do not contribute to the refresh, but which are important enough to warrant delaying the end of the refresh. That could be a matter for recommendation(s) in the standard. NB: given that the timing of the EoRR is tied to the state of the Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. At the beginning of the initial update, the Restarting and Receiving speakers have: Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In Now suppose (bonkers or otherwise) the receiving speaker sends an RRQ part way through the initial update. The restarting speaker responds with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specification. The receiving speaker sees the EoRR, and flushes stale. Unfortunately, if the restarting speaker has not yet fully populated its Adj-RIB-Out, then many further routes will be sent before the EoR falls due -- but the receiving speaker has already flushed their tiny posteriors :-( I am coming to the view that route-refresh during a Graceful Restart initial update is a horse of a different colour altogether. [So the assumption that EoRR and EoR are triggered by the same thing was completely wrong, and I apologise for it.] Chris From jakob.heitz@ericsson.com Sat Jan 25 11:48:31 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A941A002F for ; Sat, 25 Jan 2014 11:48:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIols__AwSlM for ; Sat, 25 Jan 2014 11:48:28 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id B957B1A0027 for ; Sat, 25 Jan 2014 11:48:28 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-61-52e41506a306 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 68.C9.12743.70514E25; Sat, 25 Jan 2014 20:48:23 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0387.000; Sat, 25 Jan 2014 14:48:25 -0500 From: Jakob Heitz To: Chris Hall , "idr@ietf.org" Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPF5KdKHMolEg8TF26AxOKep0T6JqRMOhAgAGfMAD//7gu+4AAX1gA//+1BTCAAHhgAP//sQGgAA5+ToAABygAoAAmsOcAAAoIr7AAJlf4AP//r6/0 Date: Sat, 25 Jan 2014 19:48:25 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F6716D@eusaamb109.ericsson.se> References: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F54ED5@eusaamb109.ericsson.se> <10eca092172d443380eccf2e8548f2a9@BLUPR09MB053.namprd09.prod.outlook.com> <98FB84F8-96B2-4D7B-8FF0-0A3DE4D90465@ericsson.com> <07a101cf1861$7cf46700$76dd3500$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F55B8C@eusaamb109.ericsson.se> <07c701cf1878$2f67aee0$8e370ca0$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F55E37@eusaamb109.ericsson.se> <13E5680B-7295-4C05-B913-C5339993FA32@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F56346@eusaamb109.ericsson.se> <085301cf1942$0bbdae70$23390b50$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F577F9@eusaamb109.ericsson.se>, <08e201cf1a03$8efad120$acf07360$@highwayman.com> In-Reply-To: <08e201cf1a03$8efad120$acf07360$@highwayman.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsUyuXSPny676JMgg8eNohbvf21jtnh1+xmT A5PH8aO7mD2WLPnJFMAUxWWTkpqTWZZapG+XwJUxr/kQU8ET3YoJE6YzNzBeVO1i5OCQEDCR +LLXoIuRE8gUk7hwbz0biC0kcIRR4vtcoDgXkL2cUaL11W4WkASbgI7Et+tdzCC2iICnxMt3 V8DiwgJuEndbPjNBxN0lWn5MYgZpFhFoYpToXDobLMEioCqxZt5ysAZeAV+J/eu6mSA23GKT uPfuP1gRp4CtxNXbUxlBbEagk76fWgMWZxYQl7j1ZD4TxKkCEkv2nGeGsEUlXj7+xwphK0lM WnqOFaJeR2LB7k9sELa2xLKFr5khFgtKnJz5hGUCo+gsJGNnIWmZhaRlFpKWBYwsqxg5SotT y3LTjQw2MQLj4ZgEm+4Oxj0vLQ8xSnOwKInzfnnrHCQkkJ5YkpqdmlqQWhRfVJqTWnyIkYmD U6qBsW/thN75r5i4Ww92H7K8ZrT7rEe0ecjVhog3PnKu/1rYV2pM/si4+1vnK6/TbTKpplLJ hz9e+pemn705sFTMu8DI2PjFHGl34UlS3Ot41/lGPzh5Ofze2op5HZn9DGfCXq7kb99lVXS+ ivWhb/3T1QHPzxRt6a1Rl5/+wHH1dVPjyK/PU4LilFiKMxINtZiLihMBxvMyLVUCAAA= Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 19:48:31 -0000 RFCs are written for coders "practiced" in the art".=0A= If anyone sends an EoRR before the adj-RIB-out is fully populated, then it'= s a BUG.=0A= This does not need to be said.=0A= =0A= Personally, I believe a route refresh request should not be honored until G= R is complete.=0A= Also, I don't believe a timer for the receipt of EoRR is necessary, because= the EoRR is guaranteed.=0A= Guaranteed means "unless the session drops first".=0A= --=0A= =0A= Jakob Heitz.=0A= =0A= ________________________________________=0A= From: Chris Hall [chris.hall@highwayman.com]=0A= Sent: Saturday, 25 January 2014 11:27 AM=0A= To: idr@ietf.org=0A= Cc: Jakob Heitz=0A= Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh=0A= =0A= Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37):=0A= ...=0A= > Silence means don't do it.=0A= =0A= Hmmm.... as a principle I'm more comfortable with "that which isn't=0A= prohibited is permitted"....=0A= =0A= > You would definitely NOT want BoRR to flush old stales.=0A= =0A= ....but, given the definite requirement, and given that the current=0A= precedent for "marking stale" does flush old stale, then a few words=0A= for the avoidance of doubt ?=0A= =0A= > Restarting the timer might be a good idea.=0A= =0A= I dunno... a route which remains stale for "a long time" is, of=0A= course, a candidate for being withdrawn: so having started a timer the=0A= first time things are set stale, I would avoid extending that -- at=0A= least for Graceful Restart, where the whole withdraw thing has been=0A= "on-hold" since the last session failed. For route-refresh I guess=0A= there's more of a presumption that stale routes will be refreshed=0A= sooner or later, and in the meantime they remain good. So if the=0A= route-refresh is (repeatedly) restarted for some reason, perhaps it is=0A= more reasonable to extend the flush deadline -- but avoid doing this=0A= indefinitely ?=0A= =0A= FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I have=0A= built in Quagga prioritise route changes (pending changes and any that=0A= occur during the refresh) over refresh updates. This makes it more=0A= likely that remaining stale routes are still good. But the other end=0A= cannot know that.=0A= =0A= The paragraph in the draft discussing the "entire Adj-RIB-Out" defines=0A= that to be the entries present "at the start of the route refresh=0A= operation", and observes that these comprise both reachable and=0A= unreachable routes. [An "of" after "comprise" sets teeth on edge,=0A= BTW.] I'm really not sure what this paragraph is trying to tell me.=0A= The reference to unreachable routes appears to suggest that pending=0A= withdraws should be sent as part of the refresh -- so not left to the=0A= EoRR to implement at the end. The point at which the EoRR is sent is=0A= defined such that it excludes any Adj-RIB-Out entries added after the=0A= route-refresh started, but includes any which are changed during the=0A= process. It seems reasonable to delay any brand new reachable=0A= prefixes until after all previously announced ones have been refreshed=0A= and the EoRR sent -- if that's the intent here. Changes which occur=0A= before the refresh gets to a given entry are pretty naturally swept up=0A= by the refresh. Changes which occur after the refresh has gone past,=0A= could/should be deferred to after the EoRR ? Does it make a=0A= difference if the change is a withdraw ? (Of course MRAI may kick in=0A= here. Ah. MRAI and route-refresh, there's a topic !)=0A= =0A= I think the essence of the rule is that the EoRR should be sent once=0A= all prefixes previously advertised to the peer as reachable have been=0A= refreshed, ie announced or withdrawn (at least) once. Or, perhaps=0A= more strictly, not *before* those prefixes have *all* been announced=0A= once -- given that the EoRR will promptly bang un-advertised stuff on=0A= the head. Even more strictly perhaps: not send EoRR *before* any=0A= withdraws implied by it are required or desirable.=0A= =0A= Depending on the implementation, a given sender may or may not be able=0A= to determine the minimum set of updates required before sending EoRR.=0A= =0A= If the refresh operation takes a long time, there may be good routeing=0A= reasons to arrange for some route changes to be sent to the peer=0A= "early" -- that is to send announcements which do not contribute to=0A= the refresh, but which are important enough to warrant delaying the=0A= end of the refresh. That could be a matter for recommendation(s) in=0A= the standard.=0A= =0A= NB: given that the timing of the EoRR is tied to the state of the=0A= Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. At=0A= the beginning of the initial update, the Restarting and Receiving=0A= speakers have:=0A= =0A= Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out=0A= =0A= Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In=0A= =0A= Now suppose (bonkers or otherwise) the receiving speaker sends an RRQ=0A= part way through the initial update. The restarting speaker responds=0A= with BoRR, everything in its Adj-RIB-Out, and EoRR -- per=0A= specification. The receiving speaker sees the EoRR, and flushes=0A= stale. Unfortunately, if the restarting speaker has not yet fully=0A= populated its Adj-RIB-Out, then many further routes will be sent=0A= before the EoR falls due -- but the receiving speaker has already=0A= flushed their tiny posteriors :-(=0A= =0A= I am coming to the view that route-refresh during a Graceful Restart=0A= initial update is a horse of a different colour altogether.=0A= =0A= [So the assumption that EoRR and EoR are triggered by the same thing=0A= was completely wrong, and I apologise for it.]=0A= =0A= Chris=0A= =0A= From jie.dong@huawei.com Sun Jan 26 00:17:22 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4041A0117 for ; Sun, 26 Jan 2014 00:17:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fia8G3bJf6g for ; Sun, 26 Jan 2014 00:17:20 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 744621A0115 for ; Sun, 26 Jan 2014 00:17:19 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCX82630; Sun, 26 Jan 2014 08:17:16 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 26 Jan 2014 08:17:03 +0000 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 26 Jan 2014 08:17:15 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.51]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Sun, 26 Jan 2014 16:17:09 +0800 From: "Dongjie (Jimmy)" To: Jakob Heitz , Chris Hall , "idr@ietf.org" Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPF5KdKHMolEg8TF26AxOKep0T6JqRMOhAgADFQgCAAAwAgIAAC4YAgAARhoCAABvfAIAABfyAgAAe94CAABsuAIABU5kAgAAED4CAAX72AIAABbyAgAFQw7A= Date: Sun, 26 Jan 2014 08:17:08 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927335C4051@nkgeml512-mbx.china.huawei.com> References: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F54ED5@eusaamb109.ericsson.se> <10eca092172d443380eccf2e8548f2a9@BLUPR09MB053.namprd09.prod.outlook.com> <98FB84F8-96B2-4D7B-8FF0-0A3DE4D90465@ericsson.com> <07a101cf1861$7cf46700$76dd3500$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F55B8C@eusaamb109.ericsson.se> <07c701cf1878$2f67aee0$8e370ca0$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F55E37@eusaamb109.ericsson.se> <13E5680B-7295-4C05-B913-C5339993FA32@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F56346@eusaamb109.ericsson.se> <085301cf1942$0bbdae70$23390b50$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F577F9@eusaamb109.ericsson.se>, <08e201cf1a03$8efad120$acf07360$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F6716D@eusaamb109.ericsson.se> In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F6716D@eusaamb109.ericsson.se> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.192.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 08:17:22 -0000 After reading the analyses in this thread, my personal feeling is maybe we = should avoid the interleaving between GR initial update and route refresh/e= nhanced route refresh, since the initial update is just sending the whole A= dj-RIB-Out, there is no obvious advantage to start a route refresh/enhance = route refresh during it. So a speaker should ignore the RRQ received during= the initial update. Thoughts? Best regards, Jie -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz Sent: Saturday, January 25, 2014 10:48 PM To: Chris Hall; idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh RFCs are written for coders "practiced" in the art". If anyone sends an EoRR before the adj-RIB-out is fully populated, then it'= s a BUG. This does not need to be said. Personally, I believe a route refresh request should not be honored until G= R is complete. Also, I don't believe a timer for the receipt of EoRR is necessary, because= the EoRR is guaranteed. Guaranteed means "unless the session drops first". -- Jakob Heitz. ________________________________________ From: Chris Hall [chris.hall@highwayman.com] Sent: Saturday, 25 January 2014 11:27 AM To: idr@ietf.org Cc: Jakob Heitz Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): ... > Silence means don't do it. Hmmm.... as a principle I'm more comfortable with "that which isn't prohibi= ted is permitted".... > You would definitely NOT want BoRR to flush old stales. ....but, given the definite requirement, and given that the current precede= nt for "marking stale" does flush old stale, then a few words for the avoid= ance of doubt ? > Restarting the timer might be a good idea. I dunno... a route which remains stale for "a long time" is, of course, a c= andidate for being withdrawn: so having started a timer the first time thin= gs are set stale, I would avoid extending that -- at least for Graceful Res= tart, where the whole withdraw thing has been "on-hold" since the last sess= ion failed. For route-refresh I guess there's more of a presumption that s= tale routes will be refreshed sooner or later, and in the meantime they rem= ain good. So if the route-refresh is (repeatedly) restarted for some reaso= n, perhaps it is more reasonable to extend the flush deadline -- but avoid = doing this indefinitely ? FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I have built = in Quagga prioritise route changes (pending changes and any that occur duri= ng the refresh) over refresh updates. This makes it more likely that remai= ning stale routes are still good. But the other end cannot know that. The paragraph in the draft discussing the "entire Adj-RIB-Out" defines that= to be the entries present "at the start of the route refresh operation", a= nd observes that these comprise both reachable and unreachable routes. [An= "of" after "comprise" sets teeth on edge, BTW.] I'm really not sure what = this paragraph is trying to tell me. The reference to unreachable routes appears to suggest that pending withdra= ws should be sent as part of the refresh -- so not left to the EoRR to impl= ement at the end. The point at which the EoRR is sent is defined such that= it excludes any Adj-RIB-Out entries added after the route-refresh started,= but includes any which are changed during the process. It seems reasonabl= e to delay any brand new reachable prefixes until after all previously anno= unced ones have been refreshed and the EoRR sent -- if that's the intent he= re. Changes which occur before the refresh gets to a given entry are prett= y naturally swept up by the refresh. Changes which occur after the refresh= has gone past, could/should be deferred to after the EoRR ? Does it make = a difference if the change is a withdraw ? (Of course MRAI may kick in her= e. Ah. MRAI and route-refresh, there's a topic !) I think the essence of the rule is that the EoRR should be sent once all pr= efixes previously advertised to the peer as reachable have been refreshed, = ie announced or withdrawn (at least) once. Or, perhaps more strictly, not = *before* those prefixes have *all* been announced once -- given that the Eo= RR will promptly bang un-advertised stuff on the head. Even more strictly = perhaps: not send EoRR *before* any withdraws implied by it are required or= desirable. Depending on the implementation, a given sender may or may not be able to d= etermine the minimum set of updates required before sending EoRR. If the refresh operation takes a long time, there may be good routeing reas= ons to arrange for some route changes to be sent to the peer "early" -- tha= t is to send announcements which do not contribute to the refresh, but whic= h are important enough to warrant delaying the end of the refresh. That co= uld be a matter for recommendation(s) in the standard. NB: given that the timing of the EoRR is tied to the state of the Adj-RIB-O= ut, I'm not sure about the Graceful Restart assumptions. At the beginning = of the initial update, the Restarting and Receiving speakers have: Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In Now suppose (bonkers or otherwise) the receiving speaker sends an RRQ part = way through the initial update. The restarting speaker responds with BoRR,= everything in its Adj-RIB-Out, and EoRR -- per specification. The receivi= ng speaker sees the EoRR, and flushes stale. Unfortunately, if the restart= ing speaker has not yet fully populated its Adj-RIB-Out, then many further = routes will be sent before the EoR falls due -- but the receiving speaker h= as already flushed their tiny posteriors :-( I am coming to the view that route-refresh during a Graceful Restart initia= l update is a horse of a different colour altogether. [So the assumption that EoRR and EoR are triggered by the same thing was co= mpletely wrong, and I apologise for it.] Chris _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From jakob.heitz@ericsson.com Sun Jan 26 01:29:27 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE341A011F for ; Sun, 26 Jan 2014 01:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCCfH44TTvxE for ; Sun, 26 Jan 2014 01:29:24 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id EA0181A0115 for ; Sun, 26 Jan 2014 01:29:23 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-96-52e4d56e40e2 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id C7.4E.12743.E65D4E25; Sun, 26 Jan 2014 10:29:19 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0387.000; Sun, 26 Jan 2014 04:29:21 -0500 From: Jakob Heitz To: "Dongjie (Jimmy)" Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPF5KdKHMolEg8TF26AxOKep0T6JqRMOhAgAGfMAD//7gu+4AAX1gA//+1BTCAAHhgAP//sQGgAA5+ToAABygAoAAmsOcAAAoIr7AAJlf4AP//r6/0gAEnPAD//8BcWg== Date: Sun, 26 Jan 2014 09:29:20 +0000 Message-ID: <00AB3F7F-5E33-4533-96C7-E7F75A3E76CB@ericsson.com> References: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F54ED5@eusaamb109.ericsson.se> <10eca092172d443380eccf2e8548f2a9@BLUPR09MB053.namprd09.prod.outlook.com> <98FB84F8-96B2-4D7B-8FF0-0A3DE4D90465@ericsson.com> <07a101cf1861$7cf46700$76dd3500$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F55B8C@eusaamb109.ericsson.se> <07c701cf1878$2f67aee0$8e370ca0$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F55E37@eusaamb109.ericsson.se> <13E5680B-7295-4C05-B913-C5339993FA32@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F56346@eusaamb109.ericsson.se> <085301cf1942$0bbdae70$23390b50$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F577F9@eusaamb109.ericsson.se>, <08e201cf1a03$8efad120$acf07360$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F6716D@eusaamb109.ericsson.se>, <76CD132C3ADEF848BD84D028D243C927335C4051@nkgeml512-mbx.china.huawei.com> In-Reply-To: <76CD132C3ADEF848BD84D028D243C927335C4051@nkgeml512-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyuXRPoG7+1SdBBpcbWCze/9rGbPHq9jMm iwk3GpgcmD2OH93F7NFy5C2rx5IlP5kCmKO4bFJSczLLUov07RK4Mr68lCuYbFJx/tQilgbG Fq0uRg4OCQETiRWTi7sYOYFMMYkL99azdTFycQgJHGGUOL5qMQuEs5xR4svkv0wgVWwCOhLf rncxgzSLCGhLzJ8fBBJmFvCU2N//BKxEWMBN4tWk5ewgtoiAu0TLj0nMIHNEBCYxSsy9dpsV JMEioCox7/0/FhCbV8BeYt/Fv6wQy16zSxxpXgK2gFMgTOLE+1CQGkag676fWsMEsUxc4taT +UwQVwtILNlznhnCFpV4+fgfK0SNjsSC3Z/YIGxtiWULXzND7BKUODnzCcsERtFZSEbNQtIy C0nLLCQtCxhZVjFylBanluWmGxlsYgTGxzEJNt0djHteWh5ilOZgURLn/fLWOUhIID2xJDU7 NbUgtSi+qDQntfgQIxMHp1QDo9TZphib+9KFJsWt68QSxDyXVqkL5OyfeIqlSv7B6heC9QUF EZuurtyseyRXQ3TryrK7dYceVc23Tstr+P/5l9WCLVx3RKeYr1Ur3z1NT2Aer90ZrR8/vr8w rZ9baHtwgd2BhVll5VGpzbE7Bfim8QVsmlqilnf32l5VjdRNL3OfBfdGL0mTUGIpzkg01GIu Kk4EAP2Z6wpdAgAA Cc: "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 09:29:27 -0000 You can definitely not ignore it, but you could postpone it. -- Jakob Heitz. > On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" wro= te: >=20 > After reading the analyses in this thread, my personal feeling is maybe w= e should avoid the interleaving between GR initial update and route refresh= /enhanced route refresh, since the initial update is just sending the whole= Adj-RIB-Out, there is no obvious advantage to start a route refresh/enhanc= e route refresh during it. So a speaker should ignore the RRQ received duri= ng the initial update. Thoughts? >=20 > Best regards, > Jie >=20 > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz > Sent: Saturday, January 25, 2014 10:48 PM > To: Chris Hall; idr@ietf.org > Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh >=20 > RFCs are written for coders "practiced" in the art". > If anyone sends an EoRR before the adj-RIB-out is fully populated, then i= t's a BUG. > This does not need to be said. >=20 > Personally, I believe a route refresh request should not be honored until= GR is complete. > Also, I don't believe a timer for the receipt of EoRR is necessary, becau= se the EoRR is guaranteed. > Guaranteed means "unless the session drops first". > -- >=20 > Jakob Heitz. >=20 > ________________________________________ > From: Chris Hall [chris.hall@highwayman.com] > Sent: Saturday, 25 January 2014 11:27 AM > To: idr@ietf.org > Cc: Jakob Heitz > Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh >=20 > Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): > ... >> Silence means don't do it. >=20 > Hmmm.... as a principle I'm more comfortable with "that which isn't prohi= bited is permitted".... >=20 >> You would definitely NOT want BoRR to flush old stales. >=20 > ....but, given the definite requirement, and given that the current prece= dent for "marking stale" does flush old stale, then a few words for the avo= idance of doubt ? >=20 >> Restarting the timer might be a good idea. >=20 > I dunno... a route which remains stale for "a long time" is, of course, a= candidate for being withdrawn: so having started a timer the first time th= ings are set stale, I would avoid extending that -- at least for Graceful R= estart, where the whole withdraw thing has been "on-hold" since the last se= ssion failed. For route-refresh I guess there's more of a presumption that= stale routes will be refreshed sooner or later, and in the meantime they r= emain good. So if the route-refresh is (repeatedly) restarted for some rea= son, perhaps it is more reasonable to extend the flush deadline -- but avoi= d doing this indefinitely ? >=20 > FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I have buil= t in Quagga prioritise route changes (pending changes and any that occur du= ring the refresh) over refresh updates. This makes it more likely that rem= aining stale routes are still good. But the other end cannot know that. >=20 > The paragraph in the draft discussing the "entire Adj-RIB-Out" defines th= at to be the entries present "at the start of the route refresh operation",= and observes that these comprise both reachable and unreachable routes. [= An "of" after "comprise" sets teeth on edge, BTW.] I'm really not sure wha= t this paragraph is trying to tell me. > The reference to unreachable routes appears to suggest that pending withd= raws should be sent as part of the refresh -- so not left to the EoRR to im= plement at the end. The point at which the EoRR is sent is defined such th= at it excludes any Adj-RIB-Out entries added after the route-refresh starte= d, but includes any which are changed during the process. It seems reasona= ble to delay any brand new reachable prefixes until after all previously an= nounced ones have been refreshed and the EoRR sent -- if that's the intent = here. Changes which occur before the refresh gets to a given entry are pre= tty naturally swept up by the refresh. Changes which occur after the refre= sh has gone past, could/should be deferred to after the EoRR ? Does it mak= e a difference if the change is a withdraw ? (Of course MRAI may kick in h= ere. Ah. MRAI and route-refresh, there's a topic !) >=20 > I think the essence of the rule is that the EoRR should be sent once all = prefixes previously advertised to the peer as reachable have been refreshed= , ie announced or withdrawn (at least) once. Or, perhaps more strictly, no= t *before* those prefixes have *all* been announced once -- given that the = EoRR will promptly bang un-advertised stuff on the head. Even more strictl= y perhaps: not send EoRR *before* any withdraws implied by it are required = or desirable. >=20 > Depending on the implementation, a given sender may or may not be able to= determine the minimum set of updates required before sending EoRR. >=20 > If the refresh operation takes a long time, there may be good routeing re= asons to arrange for some route changes to be sent to the peer "early" -- t= hat is to send announcements which do not contribute to the refresh, but wh= ich are important enough to warrant delaying the end of the refresh. That = could be a matter for recommendation(s) in the standard. >=20 > NB: given that the timing of the EoRR is tied to the state of the Adj-RIB= -Out, I'm not sure about the Graceful Restart assumptions. At the beginnin= g of the initial update, the Restarting and Receiving speakers have: >=20 > Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out >=20 > Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In >=20 > Now suppose (bonkers or otherwise) the receiving speaker sends an RRQ par= t way through the initial update. The restarting speaker responds with BoR= R, everything in its Adj-RIB-Out, and EoRR -- per specification. The recei= ving speaker sees the EoRR, and flushes stale. Unfortunately, if the resta= rting speaker has not yet fully populated its Adj-RIB-Out, then many furthe= r routes will be sent before the EoR falls due -- but the receiving speaker= has already flushed their tiny posteriors :-( >=20 > I am coming to the view that route-refresh during a Graceful Restart init= ial update is a horse of a different colour altogether. >=20 > [So the assumption that EoRR and EoR are triggered by the same thing was = completely wrong, and I apologise for it.] >=20 > Chris >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From keyupate@cisco.com Sun Jan 26 09:30:23 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E40731A0005 for ; Sun, 26 Jan 2014 09:30:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlRCVkU-rfWr for ; Sun, 26 Jan 2014 09:30:20 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4531A0004 for ; Sun, 26 Jan 2014 09:30:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7097; q=dns/txt; s=iport; t=1390757418; x=1391967018; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=rlcH1ZIl45fs3Pa6TCwLHH30Oay7hfoV7nIiLDoZGY4=; b=Q5WwArviPoSeMwM8WoaCTwDtM+Pp17mInK9f0zP9iP7FixShLw0L6qiZ qN9xgTjDuR1UO3YSN07d9h16Am7Ym5OgwiFJdlF0Un3fnXMgO7Qo6OxSn 0fecCSINr2etWZ81oiyYYkpHouYHcXUS60jNCeVtRvz1rh4E9lEpI0x+g Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAOdF5VKtJV2Z/2dsb2JhbABagww4VrxZgQQWdIIlAQEBBAEBATc0CwwGAQgRBAEBHwkuCxQJCAIEAQ0FiAUNqi2dMRMEjw0HBoQyAQOYJ5Iegy2CKg X-IronPort-AV: E=Sophos;i="4.95,724,1384300800"; d="scan'208";a="299781734" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 26 Jan 2014 17:30:12 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0QHUBr9030252 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 26 Jan 2014 17:30:11 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.228]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Sun, 26 Jan 2014 11:30:11 -0600 From: "Keyur Patel (keyupate)" To: Jakob Heitz , "Dongjie (Jimmy)" Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPGrxDnSg2v8KK+0+W7r0WcIWGPQ== Date: Sun, 26 Jan 2014 17:30:11 +0000 Message-ID: In-Reply-To: <00AB3F7F-5E33-4533-96C7-E7F75A3E76CB@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.21.89.171] Content-Type: text/plain; charset="us-ascii" Content-ID: <2E4E141AD715594685862C891497434F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 17:30:23 -0000 Jie, I agree with Jakob. You could make it *an implementation behavior* to postpone the route refresh reply. Regards, Keyur On 1/26/14 1:29 AM, "Jakob Heitz" wrote: >You can definitely not ignore it, but you could postpone it. > >-- >Jakob Heitz. > >> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" >>wrote: >>=20 >> After reading the analyses in this thread, my personal feeling is maybe >>we should avoid the interleaving between GR initial update and route >>refresh/enhanced route refresh, since the initial update is just sending >>the whole Adj-RIB-Out, there is no obvious advantage to start a route >>refresh/enhance route refresh during it. So a speaker should ignore the >>RRQ received during the initial update. Thoughts? >>=20 >> Best regards, >> Jie >>=20 >> -----Original Message----- >> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz >> Sent: Saturday, January 25, 2014 10:48 PM >> To: Chris Hall; idr@ietf.org >> Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh >>=20 >> RFCs are written for coders "practiced" in the art". >> If anyone sends an EoRR before the adj-RIB-out is fully populated, then >>it's a BUG. >> This does not need to be said. >>=20 >> Personally, I believe a route refresh request should not be honored >>until GR is complete. >> Also, I don't believe a timer for the receipt of EoRR is necessary, >>because the EoRR is guaranteed. >> Guaranteed means "unless the session drops first". >> -- >>=20 >> Jakob Heitz. >>=20 >> ________________________________________ >> From: Chris Hall [chris.hall@highwayman.com] >> Sent: Saturday, 25 January 2014 11:27 AM >> To: idr@ietf.org >> Cc: Jakob Heitz >> Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh >>=20 >> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): >> ... >>> Silence means don't do it. >>=20 >> Hmmm.... as a principle I'm more comfortable with "that which isn't >>prohibited is permitted".... >>=20 >>> You would definitely NOT want BoRR to flush old stales. >>=20 >> ....but, given the definite requirement, and given that the current >>precedent for "marking stale" does flush old stale, then a few words for >>the avoidance of doubt ? >>=20 >>> Restarting the timer might be a good idea. >>=20 >> I dunno... a route which remains stale for "a long time" is, of course, >>a candidate for being withdrawn: so having started a timer the first >>time things are set stale, I would avoid extending that -- at least for >>Graceful Restart, where the whole withdraw thing has been "on-hold" >>since the last session failed. For route-refresh I guess there's more >>of a presumption that stale routes will be refreshed sooner or later, >>and in the meantime they remain good. So if the route-refresh is >>(repeatedly) restarted for some reason, perhaps it is more reasonable to >>extend the flush deadline -- but avoid doing this indefinitely ? >>=20 >> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I have >>built in Quagga prioritise route changes (pending changes and any that >>occur during the refresh) over refresh updates. This makes it more >>likely that remaining stale routes are still good. But the other end >>cannot know that. >>=20 >> The paragraph in the draft discussing the "entire Adj-RIB-Out" defines >>that to be the entries present "at the start of the route refresh >>operation", and observes that these comprise both reachable and >>unreachable routes. [An "of" after "comprise" sets teeth on edge, BTW.] >> I'm really not sure what this paragraph is trying to tell me. >> The reference to unreachable routes appears to suggest that pending >>withdraws should be sent as part of the refresh -- so not left to the >>EoRR to implement at the end. The point at which the EoRR is sent is >>defined such that it excludes any Adj-RIB-Out entries added after the >>route-refresh started, but includes any which are changed during the >>process. It seems reasonable to delay any brand new reachable prefixes >>until after all previously announced ones have been refreshed and the >>EoRR sent -- if that's the intent here. Changes which occur before the >>refresh gets to a given entry are pretty naturally swept up by the >>refresh. Changes which occur after the refresh has gone past, >>could/should be deferred to after the EoRR ? Does it make a difference >>if the change is a withdraw ? (Of course MRAI may kick in here. Ah. >>MRAI and route-refresh, there's a topic !) >>=20 >> I think the essence of the rule is that the EoRR should be sent once >>all prefixes previously advertised to the peer as reachable have been >>refreshed, ie announced or withdrawn (at least) once. Or, perhaps more >>strictly, not *before* those prefixes have *all* been announced once -- >>given that the EoRR will promptly bang un-advertised stuff on the head. >>Even more strictly perhaps: not send EoRR *before* any withdraws implied >>by it are required or desirable. >>=20 >> Depending on the implementation, a given sender may or may not be able >>to determine the minimum set of updates required before sending EoRR. >>=20 >> If the refresh operation takes a long time, there may be good routeing >>reasons to arrange for some route changes to be sent to the peer "early" >>-- that is to send announcements which do not contribute to the refresh, >>but which are important enough to warrant delaying the end of the >>refresh. That could be a matter for recommendation(s) in the standard. >>=20 >> NB: given that the timing of the EoRR is tied to the state of the >>Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. At >>the beginning of the initial update, the Restarting and Receiving >>speakers have: >>=20 >> Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out >>=20 >> Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In >>=20 >> Now suppose (bonkers or otherwise) the receiving speaker sends an RRQ >>part way through the initial update. The restarting speaker responds >>with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specification. >> The receiving speaker sees the EoRR, and flushes stale. Unfortunately, >>if the restarting speaker has not yet fully populated its Adj-RIB-Out, >>then many further routes will be sent before the EoR falls due -- but >>the receiving speaker has already flushed their tiny posteriors :-( >>=20 >> I am coming to the view that route-refresh during a Graceful Restart >>initial update is a horse of a different colour altogether. >>=20 >> [So the assumption that EoRR and EoR are triggered by the same thing >>was completely wrong, and I apologise for it.] >>=20 >> Chris >>=20 >> _______________________________________________ >> 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 jie.dong@huawei.com Sun Jan 26 10:13:41 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC15F1A0023 for ; Sun, 26 Jan 2014 10:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jzOBRY3Kz9B for ; Sun, 26 Jan 2014 10:13:38 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D47CC1A000A for ; Sun, 26 Jan 2014 10:13:37 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCY10574; Sun, 26 Jan 2014 18:13:34 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 26 Jan 2014 18:13:17 +0000 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 26 Jan 2014 18:13:29 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.51]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Mon, 27 Jan 2014 02:13:25 +0800 From: "Dongjie (Jimmy)" To: "Keyur Patel (keyupate)" , Jakob Heitz Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPF5KdKHMolEg8TF26AxOKep0T6JqRMOhAgADFQgCAAAwAgIAAC4YAgAARhoCAABvfAIAABfyAgAAe94CAABsuAIABU5kAgAAED4CAAX72AIAABbyAgAFQw7D//5SZAIAAhlqAgACM4rA= Date: Sun, 26 Jan 2014 18:13:24 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927335C435C@nkgeml512-mbx.china.huawei.com> References: <00AB3F7F-5E33-4533-96C7-E7F75A3E76CB@ericsson.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.194.82] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 18:13:42 -0000 Hi Keyur, Jakob, Agree that "postpone" may be better. The point is we could avoid the compli= cated cases/considerations of performing route refresh during initial updat= e:)=20 For "ignore", I was thinking of scenarios in which the route refresh requir= ement may already be met by the initial update, while I'd admit it is hard = to say... Best regards, Jie -----Original Message----- From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com]=20 Sent: Sunday, January 26, 2014 8:30 PM To: Jakob Heitz; Dongjie (Jimmy) Cc: idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Jie, I agree with Jakob. You could make it *an implementation behavior* to postp= one the route refresh reply. Regards, Keyur On 1/26/14 1:29 AM, "Jakob Heitz" wrote: >You can definitely not ignore it, but you could postpone it. > >-- >Jakob Heitz. > >> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" >>wrote: >>=20 >> After reading the analyses in this thread, my personal feeling is=20 >>maybe we should avoid the interleaving between GR initial update and=20 >>route refresh/enhanced route refresh, since the initial update is just=20 >>sending the whole Adj-RIB-Out, there is no obvious advantage to start=20 >>a route refresh/enhance route refresh during it. So a speaker should=20 >>ignore the RRQ received during the initial update. Thoughts? >>=20 >> Best regards, >> Jie >>=20 >> -----Original Message----- >> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz >> Sent: Saturday, January 25, 2014 10:48 PM >> To: Chris Hall; idr@ietf.org >> Subject: Re: [Idr] WG LC for=20 >> draft-ietf-idr-bgp-enhanced-route-refresh >>=20 >> RFCs are written for coders "practiced" in the art". >> If anyone sends an EoRR before the adj-RIB-out is fully populated,=20 >>then it's a BUG. >> This does not need to be said. >>=20 >> Personally, I believe a route refresh request should not be honored=20 >>until GR is complete. >> Also, I don't believe a timer for the receipt of EoRR is necessary,=20 >>because the EoRR is guaranteed. >> Guaranteed means "unless the session drops first". >> -- >>=20 >> Jakob Heitz. >>=20 >> ________________________________________ >> From: Chris Hall [chris.hall@highwayman.com] >> Sent: Saturday, 25 January 2014 11:27 AM >> To: idr@ietf.org >> Cc: Jakob Heitz >> Subject: RE: [Idr] WG LC for=20 >> draft-ietf-idr-bgp-enhanced-route-refresh >>=20 >> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): >> ... >>> Silence means don't do it. >>=20 >> Hmmm.... as a principle I'm more comfortable with "that which isn't=20 >>prohibited is permitted".... >>=20 >>> You would definitely NOT want BoRR to flush old stales. >>=20 >> ....but, given the definite requirement, and given that the current=20 >>precedent for "marking stale" does flush old stale, then a few words=20 >>for the avoidance of doubt ? >>=20 >>> Restarting the timer might be a good idea. >>=20 >> I dunno... a route which remains stale for "a long time" is, of=20 >>course, a candidate for being withdrawn: so having started a timer the=20 >>first time things are set stale, I would avoid extending that -- at=20 >>least for Graceful Restart, where the whole withdraw thing has been "on-h= old" >>since the last session failed. For route-refresh I guess there's more=20 >>of a presumption that stale routes will be refreshed sooner or later,=20 >>and in the meantime they remain good. So if the route-refresh is >>(repeatedly) restarted for some reason, perhaps it is more reasonable=20 >>to extend the flush deadline -- but avoid doing this indefinitely ? >>=20 >> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I have=20 >>built in Quagga prioritise route changes (pending changes and any that=20 >>occur during the refresh) over refresh updates. This makes it more=20 >>likely that remaining stale routes are still good. But the other end=20 >>cannot know that. >>=20 >> The paragraph in the draft discussing the "entire Adj-RIB-Out"=20 >>defines that to be the entries present "at the start of the route=20 >>refresh operation", and observes that these comprise both reachable=20 >>and unreachable routes. [An "of" after "comprise" sets teeth on edge,=20 >>BTW.] I'm really not sure what this paragraph is trying to tell me. >> The reference to unreachable routes appears to suggest that pending=20 >>withdraws should be sent as part of the refresh -- so not left to the=20 >>EoRR to implement at the end. The point at which the EoRR is sent is=20 >>defined such that it excludes any Adj-RIB-Out entries added after the=20 >>route-refresh started, but includes any which are changed during the=20 >>process. It seems reasonable to delay any brand new reachable=20 >>prefixes until after all previously announced ones have been refreshed=20 >>and the EoRR sent -- if that's the intent here. Changes which occur=20 >>before the refresh gets to a given entry are pretty naturally swept up=20 >>by the refresh. Changes which occur after the refresh has gone past,=20 >>could/should be deferred to after the EoRR ? Does it make a=20 >>difference if the change is a withdraw ? (Of course MRAI may kick in her= e. Ah. >>MRAI and route-refresh, there's a topic !) >>=20 >> I think the essence of the rule is that the EoRR should be sent once=20 >>all prefixes previously advertised to the peer as reachable have been=20 >>refreshed, ie announced or withdrawn (at least) once. Or, perhaps=20 >>more strictly, not *before* those prefixes have *all* been announced=20 >>once -- given that the EoRR will promptly bang un-advertised stuff on the= head. >>Even more strictly perhaps: not send EoRR *before* any withdraws=20 >>implied by it are required or desirable. >>=20 >> Depending on the implementation, a given sender may or may not be=20 >>able to determine the minimum set of updates required before sending EoRR= . >>=20 >> If the refresh operation takes a long time, there may be good=20 >>routeing reasons to arrange for some route changes to be sent to the peer= "early" >>-- that is to send announcements which do not contribute to the=20 >>refresh, but which are important enough to warrant delaying the end of=20 >>the refresh. That could be a matter for recommendation(s) in the standar= d. >>=20 >> NB: given that the timing of the EoRR is tied to the state of the=20 >>Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. At=20 >>the beginning of the initial update, the Restarting and Receiving=20 >>speakers have: >>=20 >> Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out >>=20 >> Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In >>=20 >> Now suppose (bonkers or otherwise) the receiving speaker sends an RRQ=20 >>part way through the initial update. The restarting speaker responds=20 >>with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specification. >> The receiving speaker sees the EoRR, and flushes stale. =20 >>Unfortunately, if the restarting speaker has not yet fully populated=20 >>its Adj-RIB-Out, then many further routes will be sent before the EoR=20 >>falls due -- but the receiving speaker has already flushed their tiny=20 >>posteriors :-( >>=20 >> I am coming to the view that route-refresh during a Graceful Restart=20 >>initial update is a horse of a different colour altogether. >>=20 >> [So the assumption that EoRR and EoR are triggered by the same thing=20 >>was completely wrong, and I apologise for it.] >>=20 >> Chris >>=20 >> _______________________________________________ >> 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 rraszuk@gmail.com Sun Jan 26 12:02:49 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4691A0069 for ; Sun, 26 Jan 2014 12:02:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyOSqcMZPFzV for ; Sun, 26 Jan 2014 12:02:45 -0800 (PST) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 997BB1A0014 for ; Sun, 26 Jan 2014 12:02:45 -0800 (PST) Received: by mail-ig0-f171.google.com with SMTP id uy17so7209190igb.4 for ; Sun, 26 Jan 2014 12:02:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=3cNHyRrReO5PIJKeE8g8CYkpVGBISbOQqeJ+rJOAQyk=; b=KVQO91d9lOS+HzISDgqJHrTaJWtNUe9nty7RE1+dN9rz1EWb9QYLKf5pJraEqQ/+wE Iag91ApfDBUvNPGsYsfQZLl34GleTi61msYiPgL48kPHNrVZJ0SpVgXYaCumHjazIeyx FC2YNNTpzE7vwZROz/8+2YHkm3O4BxLTRnB4XjTwlAUAxoD30spC825XY1gLyroIfzGh qc66w4t3Hun7E37G5+o/3RIe0pMPgQy9dwKSBIQddBDi5y54c90PkEwHXCpcj4O8EWwF EmOpJCIOSH5iCUafIDk5pGBxtPxMHry8QOiZKnAeh8GTCLgUN8HQVJAQNDRguwShTB78 QA3g== MIME-Version: 1.0 X-Received: by 10.50.149.170 with SMTP id ub10mr14502652igb.9.1390766563597; Sun, 26 Jan 2014 12:02:43 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.212.8 with HTTP; Sun, 26 Jan 2014 12:02:43 -0800 (PST) In-Reply-To: <76CD132C3ADEF848BD84D028D243C927335C435C@nkgeml512-mbx.china.huawei.com> References: <00AB3F7F-5E33-4533-96C7-E7F75A3E76CB@ericsson.com> <76CD132C3ADEF848BD84D028D243C927335C435C@nkgeml512-mbx.china.huawei.com> Date: Sun, 26 Jan 2014 21:02:43 +0100 X-Google-Sender-Auth: 8ypOk6F3a5KcvElGW3MW41-Ah_g Message-ID: From: Robert Raszuk To: "Dongjie (Jimmy)" Content-Type: multipart/alternative; boundary=e89a8f3ba309fd2a5804f0e51224 Cc: "Keyur Patel \(keyupate\)" , "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 20:02:49 -0000 --e89a8f3ba309fd2a5804f0e51224 Content-Type: text/plain; charset=ISO-8859-1 Hi Jie, I think it actually very easy to say that initial update can not ever guarantee that RRQ received during its sending may meet the peer's need. Example 1: SAFI 128 - During receiving initial update from RR to PE new VRF got added with new RT import. Unfortunately those updates received within initial update were already dropped as not interesting by the PE. RR must resend full table after completed initial update. (Of course this is the case where there is no RTC and that's why RTC helps a lot here by incremental nature). Example 2: SAFI 1 - Operator has modified inbound policy on EBGP peer during processing of incoming updates and those originally were dropped. No soft reconfig in set. Conclusion: RRQ can not ever be ignored. Sure they can be delayed or batched (case of multiple peers within the same update/peer group) sending near RRQs (cluster of PEs got provisioned from central management station). But as Keyur already mentioned those are rather standard local implementation optimizations. Question: Does it maybe make sense to stop initial update when receiving RRQ from a peer and start over ? Of course if peer is part of large update group it would have to be removed dynamically from it so other members are not delayed. In any case I think this does not impact the spec but the implementation. Cheers, R. On Sun, Jan 26, 2014 at 7:13 PM, Dongjie (Jimmy) wrote: > Hi Keyur, Jakob, > > Agree that "postpone" may be better. The point is we could avoid the > complicated cases/considerations of performing route refresh during initial > update:) > > For "ignore", I was thinking of scenarios in which the route refresh > requirement may already be met by the initial update, while I'd admit it is > hard to say... > > > Best regards, > Jie > > -----Original Message----- > From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] > Sent: Sunday, January 26, 2014 8:30 PM > To: Jakob Heitz; Dongjie (Jimmy) > Cc: idr@ietf.org > Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh > > Jie, > > I agree with Jakob. You could make it *an implementation behavior* to > postpone the route refresh reply. > > > Regards, > Keyur > > On 1/26/14 1:29 AM, "Jakob Heitz" wrote: > > >You can definitely not ignore it, but you could postpone it. > > > >-- > >Jakob Heitz. > > > >> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" > >>wrote: > >> > >> After reading the analyses in this thread, my personal feeling is > >>maybe we should avoid the interleaving between GR initial update and > >>route refresh/enhanced route refresh, since the initial update is just > >>sending the whole Adj-RIB-Out, there is no obvious advantage to start > >>a route refresh/enhance route refresh during it. So a speaker should > >>ignore the RRQ received during the initial update. Thoughts? > >> > >> Best regards, > >> Jie > >> > >> -----Original Message----- > >> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz > >> Sent: Saturday, January 25, 2014 10:48 PM > >> To: Chris Hall; idr@ietf.org > >> Subject: Re: [Idr] WG LC for > >> draft-ietf-idr-bgp-enhanced-route-refresh > >> > >> RFCs are written for coders "practiced" in the art". > >> If anyone sends an EoRR before the adj-RIB-out is fully populated, > >>then it's a BUG. > >> This does not need to be said. > >> > >> Personally, I believe a route refresh request should not be honored > >>until GR is complete. > >> Also, I don't believe a timer for the receipt of EoRR is necessary, > >>because the EoRR is guaranteed. > >> Guaranteed means "unless the session drops first". > >> -- > >> > >> Jakob Heitz. > >> > >> ________________________________________ > >> From: Chris Hall [chris.hall@highwayman.com] > >> Sent: Saturday, 25 January 2014 11:27 AM > >> To: idr@ietf.org > >> Cc: Jakob Heitz > >> Subject: RE: [Idr] WG LC for > >> draft-ietf-idr-bgp-enhanced-route-refresh > >> > >> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): > >> ... > >>> Silence means don't do it. > >> > >> Hmmm.... as a principle I'm more comfortable with "that which isn't > >>prohibited is permitted".... > >> > >>> You would definitely NOT want BoRR to flush old stales. > >> > >> ....but, given the definite requirement, and given that the current > >>precedent for "marking stale" does flush old stale, then a few words > >>for the avoidance of doubt ? > >> > >>> Restarting the timer might be a good idea. > >> > >> I dunno... a route which remains stale for "a long time" is, of > >>course, a candidate for being withdrawn: so having started a timer the > >>first time things are set stale, I would avoid extending that -- at > >>least for Graceful Restart, where the whole withdraw thing has been > "on-hold" > >>since the last session failed. For route-refresh I guess there's more > >>of a presumption that stale routes will be refreshed sooner or later, > >>and in the meantime they remain good. So if the route-refresh is > >>(repeatedly) restarted for some reason, perhaps it is more reasonable > >>to extend the flush deadline -- but avoid doing this indefinitely ? > >> > >> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I have > >>built in Quagga prioritise route changes (pending changes and any that > >>occur during the refresh) over refresh updates. This makes it more > >>likely that remaining stale routes are still good. But the other end > >>cannot know that. > >> > >> The paragraph in the draft discussing the "entire Adj-RIB-Out" > >>defines that to be the entries present "at the start of the route > >>refresh operation", and observes that these comprise both reachable > >>and unreachable routes. [An "of" after "comprise" sets teeth on edge, > >>BTW.] I'm really not sure what this paragraph is trying to tell me. > >> The reference to unreachable routes appears to suggest that pending > >>withdraws should be sent as part of the refresh -- so not left to the > >>EoRR to implement at the end. The point at which the EoRR is sent is > >>defined such that it excludes any Adj-RIB-Out entries added after the > >>route-refresh started, but includes any which are changed during the > >>process. It seems reasonable to delay any brand new reachable > >>prefixes until after all previously announced ones have been refreshed > >>and the EoRR sent -- if that's the intent here. Changes which occur > >>before the refresh gets to a given entry are pretty naturally swept up > >>by the refresh. Changes which occur after the refresh has gone past, > >>could/should be deferred to after the EoRR ? Does it make a > >>difference if the change is a withdraw ? (Of course MRAI may kick in > here. Ah. > >>MRAI and route-refresh, there's a topic !) > >> > >> I think the essence of the rule is that the EoRR should be sent once > >>all prefixes previously advertised to the peer as reachable have been > >>refreshed, ie announced or withdrawn (at least) once. Or, perhaps > >>more strictly, not *before* those prefixes have *all* been announced > >>once -- given that the EoRR will promptly bang un-advertised stuff on > the head. > >>Even more strictly perhaps: not send EoRR *before* any withdraws > >>implied by it are required or desirable. > >> > >> Depending on the implementation, a given sender may or may not be > >>able to determine the minimum set of updates required before sending > EoRR. > >> > >> If the refresh operation takes a long time, there may be good > >>routeing reasons to arrange for some route changes to be sent to the > peer "early" > >>-- that is to send announcements which do not contribute to the > >>refresh, but which are important enough to warrant delaying the end of > >>the refresh. That could be a matter for recommendation(s) in the > standard. > >> > >> NB: given that the timing of the EoRR is tied to the state of the > >>Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. At > >>the beginning of the initial update, the Restarting and Receiving > >>speakers have: > >> > >> Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out > >> > >> Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In > >> > >> Now suppose (bonkers or otherwise) the receiving speaker sends an RRQ > >>part way through the initial update. The restarting speaker responds > >>with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specification. > >> The receiving speaker sees the EoRR, and flushes stale. > >>Unfortunately, if the restarting speaker has not yet fully populated > >>its Adj-RIB-Out, then many further routes will be sent before the EoR > >>falls due -- but the receiving speaker has already flushed their tiny > >>posteriors :-( > >> > >> I am coming to the view that route-refresh during a Graceful Restart > >>initial update is a horse of a different colour altogether. > >> > >> [So the assumption that EoRR and EoR are triggered by the same thing > >>was completely wrong, and I apologise for it.] > >> > >> Chris > >> > >> _______________________________________________ > >> 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 > --e89a8f3ba309fd2a5804f0e51224 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Jie,

I think it actually very easy to say that initial update can not ever guara= ntee that RRQ received during its sending may meet the peer's need.

Example 1:

SAFI 128 - During receiving initial update from RR to PE new VRF got added = with new RT import. Unfortunately those updates received within initial upd= ate were already dropped as not interesting by the PE. RR must resend full = table after completed initial update. (Of course this is the case where the= re is no RTC and that's why RTC helps a lot here by incremental nature)= .=A0

Example 2:=A0

SAFI 1 - Operator has modified inbound policy on EB= GP peer during processing of incoming updates and those originally were dro= pped. No soft reconfig in set.=A0

Conclusion:

RRQ can not ever be ignored. Sure they can be delay= ed or batched (case of multiple peers within the same update/peer group) se= nding near RRQs (cluster of PEs got provisioned from central management sta= tion). But as Keyur already mentioned those are rather standard local imple= mentation optimizations.=A0

Question:

Does it maybe make sense to stop initial update whe= n receiving RRQ from a peer and start over ? Of course if peer is part of l= arge update group it would have to be removed dynamically from it so other = members are not delayed. In any case I think this does not impact the spec = but the implementation.

Cheers,
R.



On Sun, Jan 26, 2014 at 7:13 PM, Dongjie (Jimmy) <jie.d= ong@huawei.com> wrote:
Hi Keyur, Jakob,

Agree that "postpone" may be better. The point is we could avoid = the complicated cases/considerations of performing route refresh during ini= tial update:)

For "ignore", I was thinking of scenarios in which the route refr= esh requirement may already be met by the initial update, while I'd adm= it it is hard to say...


Best regards,
Jie

-----Original Message-----
From: Keyur Patel (keyupate) = [mailto:keyupate@cisco.com]
Sent: Sunday, January 26, 2014 8:30 PM
To: Jakob Heitz; Dongjie (Jimmy)
Cc: idr@ietf.org
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Jie,

I agree with Jakob. You could make it *an implementation behavior* to postp= one the route refresh reply.


Regards,
Keyur

On 1/26/14 1:29 AM, "Jakob Heitz" <jakob.heitz@ericsson.com> wrote:

>You can definitely not ignore it, but you could postpone it.
>
>--
>Jakob Heitz.
>
>> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" <jie.dong@huawei.com>
>>wrote:
>>
>> After reading the analyses in this thread, my personal feeling is<= br> >>maybe we should avoid the interleaving between GR initial update an= d
>>route refresh/enhanced route refresh, since the initial update is j= ust
>>sending the whole Adj-RIB-Out, there is no obvious advantage to sta= rt
>>a route refresh/enhance route refresh during it. So a speaker shoul= d
>>ignore the RRQ received during the initial update. Thoughts?
>>
>> Best regards,
>> Jie
>>
>> -----Original Message-----
>> From: Idr [mailto:idr-boun= ces@ietf.org] On Behalf Of Jakob Heitz
>> Sent: Saturday, January 25, 2014 10:48 PM
>> To: Chris Hall; idr@ietf.org >> Subject: Re: [Idr] WG LC for
>> draft-ietf-idr-bgp-enhanced-route-refresh
>>
>> RFCs are written for coders "practiced" in the art"= .
>> If anyone sends an EoRR before the adj-RIB-out is fully populated,=
>>then it's a BUG.
>> This does not need to be said.
>>
>> Personally, I believe a route refresh request should not be honore= d
>>until GR is complete.
>> Also, I don't believe a timer for the receipt of EoRR is neces= sary,
>>because the EoRR is guaranteed.
>> Guaranteed means "unless the session drops first".
>> --
>>
>> Jakob Heitz.
>>
>> ________________________________________
>> From: Chris Hall [chr= is.hall@highwayman.com]
>> Sent: Saturday, 25 January 2014 11:27 AM
>> To: idr@ietf.org
>> Cc: Jakob Heitz
>> Subject: RE: [Idr] WG LC for
>> draft-ietf-idr-bgp-enhanced-route-refresh
>>
>> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37):
>> ...
>>> Silence means don't do it.
>>
>> Hmmm.... as a principle I'm more comfortable with "that w= hich isn't
>>prohibited is permitted"....
>>
>>> You would definitely NOT want BoRR to flush old stales.
>>
>> ....but, given the definite requirement, and given that the curren= t
>>precedent for "marking stale" does flush old stale, then = a few words
>>for the avoidance of doubt ?
>>
>>> Restarting the timer might be a good idea.
>>
>> I dunno... a route which remains stale for "a long time"= is, of
>>course, a candidate for being withdrawn: so having started a timer = the
>>first time things are set stale, I would avoid extending that -- at=
>>least for Graceful Restart, where the whole withdraw thing has been= "on-hold"
>>since the last session failed. =A0For route-refresh I guess there&#= 39;s more
>>of a presumption that stale routes will be refreshed sooner or late= r,
>>and in the meantime they remain good. =A0So if the route-refresh is=
>>(repeatedly) restarted for some reason, perhaps it is more reasonab= le
>>to extend the flush deadline -- but avoid doing this indefinitely ?=
>>
>> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I ha= ve
>>built in Quagga prioritise route changes (pending changes and any t= hat
>>occur during the refresh) over refresh updates. =A0This makes it mo= re
>>likely that remaining stale routes are still good. =A0But the other= end
>>cannot know that.
>>
>> The paragraph in the draft discussing the "entire Adj-RIB-Out= "
>>defines that to be the entries present "at the start of the ro= ute
>>refresh operation", and observes that these comprise both reac= hable
>>and unreachable routes. =A0[An "of" after "comprise&= quot; sets teeth on edge,
>>BTW.] =A0I'm really not sure what this paragraph is trying to t= ell me.
>> The reference to unreachable routes appears to suggest that pendin= g
>>withdraws should be sent as part of the refresh -- so not left to t= he
>>EoRR to implement at the end. =A0The point at which the EoRR is sen= t is
>>defined such that it excludes any Adj-RIB-Out entries added after t= he
>>route-refresh started, but includes any which are changed during th= e
>>process. =A0It seems reasonable to delay any brand new reachable >>prefixes until after all previously announced ones have been refres= hed
>>and the EoRR sent -- if that's the intent here. =A0Changes whic= h occur
>>before the refresh gets to a given entry are pretty naturally swept= up
>>by the refresh. =A0Changes which occur after the refresh has gone p= ast,
>>could/should be deferred to after the EoRR ? =A0Does it make a
>>difference if the change is a withdraw ? =A0(Of course MRAI may kic= k in here. =A0Ah.
>>MRAI and route-refresh, there's a topic !)
>>
>> I think the essence of the rule is that the EoRR should be sent on= ce
>>all prefixes previously advertised to the peer as reachable have be= en
>>refreshed, ie announced or withdrawn (at least) once. =A0Or, perhap= s
>>more strictly, not *before* those prefixes have *all* been announce= d
>>once -- given that the EoRR will promptly bang un-advertised stuff = on the head.
>>Even more strictly perhaps: not send EoRR *before* any withdraws >>implied by it are required or desirable.
>>
>> Depending on the implementation, a given sender may or may not be<= br> >>able to determine the minimum set of updates required before sendin= g EoRR.
>>
>> If the refresh operation takes a long time, there may be good
>>routeing reasons to arrange for some route changes to be sent to th= e peer "early"
>>-- that is to send announcements which do not contribute to the
>>refresh, but which are important enough to warrant delaying the end= of
>>the refresh. =A0That could be a matter for recommendation(s) in the= standard.
>>
>> NB: given that the timing of the EoRR is tied to the state of the<= br> >>Adj-RIB-Out, I'm not sure about the Graceful Restart assumption= s. =A0At
>>the beginning of the initial update, the Restarting and Receiving >>speakers have:
>>
>> =A0Restarting: =A0Empty Adj-RIB-In =A0 Empty Adj-RIB-Out
>>
>> =A0Receiving: =A0 Empty Adj-RIB-Out =A0Stale Adj-RIB-In
>>
>> Now suppose (bonkers or otherwise) the receiving speaker sends an = RRQ
>>part way through the initial update. =A0The restarting speaker resp= onds
>>with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specifica= tion.
>> The receiving speaker sees the EoRR, and flushes stale.
>>Unfortunately, if the restarting speaker has not yet fully populate= d
>>its Adj-RIB-Out, then many further routes will be sent before the E= oR
>>falls due -- but the receiving speaker has already flushed their ti= ny
>>posteriors :-(
>>
>> I am coming to the view that route-refresh during a Graceful Resta= rt
>>initial update is a horse of a different colour altogether.
>>
>> [So the assumption that EoRR and EoR are triggered by the same thi= ng
>>was completely wrong, and I apologise for it.]
>>
>> Chris
>>
>> _______________________________________________
>> 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
htt= ps://www.ietf.org/mailman/listinfo/idr

--e89a8f3ba309fd2a5804f0e51224-- From enkechen@cisco.com Sun Jan 26 14:56:24 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3CD1A00E7 for ; Sun, 26 Jan 2014 14:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMQR9dvIGlxx for ; Sun, 26 Jan 2014 14:56: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 F28E21A0090 for ; Sun, 26 Jan 2014 14:56:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7120; q=dns/txt; s=iport; t=1390776980; x=1391986580; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=oi1wf1w65YUbjmvt/Cskqd3uJmBROVsMhXbe6Z1dfhg=; b=e9RHtiW1QqV1cYORB60MVOFhFDXxaIjioZhHIYJRdbp7I5eszXWo/xRN K9JJu1bQaQgKI4mYUJS0QZFDkaLNFd9LjQouLNePoNlDBgopzxTSJ4kI+ Q2Gii3dY454La066t0PkrILOPOIKCHPbHnCTLj8BKb74ejzYxdsZ8EiX1 c=; X-IronPort-AV: E=Sophos;i="4.95,725,1384300800"; d="scan'208";a="100854818" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 26 Jan 2014 22:56:20 +0000 Received: from [10.21.78.28] ([10.21.78.28]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0QMu77r011013; Sun, 26 Jan 2014 22:56:07 GMT Message-ID: <52E59287.3080703@cisco.com> Date: Sun, 26 Jan 2014 14:56:07 -0800 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Jakob Heitz , "Dongjie (Jimmy)" , Chris Hall , Robert Raszuk References: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F54ED5@eusaamb109.ericsson.se> <10eca092172d443380eccf2e8548f2a9@BLUPR09MB053.namprd09.prod.outlook.com> <98FB84F8-96B2-4D7B-8FF0-0A3DE4D90465@ericsson.com> <07a101cf1861$7cf46700$76dd3500$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F55B8C@eusaamb109.ericsson.se> <07c701cf1878$2f67aee0$8e370ca0$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F55E37@eusaamb109.ericsson.se> <13E5680B-7295-4C05-B913-C5339993FA32@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F56346@eusaamb109.ericsson.se> <085301cf1942$0bbdae70$23390b50$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F577F9@eusaamb109.ericsson.se>, <08e201cf1a03$8efad120$acf07360$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F6716D@eusaamb109.ericsson.se>, <76CD132C3ADEF848BD84D028D243C927335C4051@nkgeml512-mbx.china.huawei.com> <00AB3F7F-5E33-4533-96C7-E7F75A3E76CB@ericsson.com> In-Reply-To: <00AB3F7F-5E33-4533-96C7-E7F75A3E76CB@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Keyur Patel , "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 22:56:25 -0000 Hi, Folks: Thanks to Chris for bringing up this interesting interaction between EOR and EoRR. How about the following text to address the issue: For a BGP speaker that supports the BGP Graceful Restart specified in [RFC4724] , it MUST NOT send an EoRR for an AFI/SAFI to a neighbor before it sends the EOR for the AFI/SAFI to the neighbor. This procedure would help the neighbor avoid the premature cleanup of stale routes. -- Enke On 1/26/14 1:29 AM, Jakob Heitz wrote: > You can definitely not ignore it, but you could postpone it. > > -- > Jakob Heitz. > >> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" wrote: >> >> After reading the analyses in this thread, my personal feeling is maybe we should avoid the interleaving between GR initial update and route refresh/enhanced route refresh, since the initial update is just sending the whole Adj-RIB-Out, there is no obvious advantage to start a route refresh/enhance route refresh during it. So a speaker should ignore the RRQ received during the initial update. Thoughts? >> >> Best regards, >> Jie >> >> -----Original Message----- >> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz >> Sent: Saturday, January 25, 2014 10:48 PM >> To: Chris Hall; idr@ietf.org >> Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh >> >> RFCs are written for coders "practiced" in the art". >> If anyone sends an EoRR before the adj-RIB-out is fully populated, then it's a BUG. >> This does not need to be said. >> >> Personally, I believe a route refresh request should not be honored until GR is complete. >> Also, I don't believe a timer for the receipt of EoRR is necessary, because the EoRR is guaranteed. >> Guaranteed means "unless the session drops first". >> -- >> >> Jakob Heitz. >> >> ________________________________________ >> From: Chris Hall [chris.hall@highwayman.com] >> Sent: Saturday, 25 January 2014 11:27 AM >> To: idr@ietf.org >> Cc: Jakob Heitz >> Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh >> >> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): >> ... >>> Silence means don't do it. >> Hmmm.... as a principle I'm more comfortable with "that which isn't prohibited is permitted".... >> >>> You would definitely NOT want BoRR to flush old stales. >> ....but, given the definite requirement, and given that the current precedent for "marking stale" does flush old stale, then a few words for the avoidance of doubt ? >> >>> Restarting the timer might be a good idea. >> I dunno... a route which remains stale for "a long time" is, of course, a candidate for being withdrawn: so having started a timer the first time things are set stale, I would avoid extending that -- at least for Graceful Restart, where the whole withdraw thing has been "on-hold" since the last session failed. For route-refresh I guess there's more of a presumption that stale routes will be refreshed sooner or later, and in the meantime they remain good. So if the route-refresh is (repeatedly) restarted for some reason, perhaps it is more reasonable to extend the flush deadline -- but avoid doing this indefinitely ? >> >> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I have built in Quagga prioritise route changes (pending changes and any that occur during the refresh) over refresh updates. This makes it more likely that remaining stale routes are still good. But the other end cannot know that. >> >> The paragraph in the draft discussing the "entire Adj-RIB-Out" defines that to be the entries present "at the start of the route refresh operation", and observes that these comprise both reachable and unreachable routes. [An "of" after "comprise" sets teeth on edge, BTW.] I'm really not sure what this paragraph is trying to tell me. >> The reference to unreachable routes appears to suggest that pending withdraws should be sent as part of the refresh -- so not left to the EoRR to implement at the end. The point at which the EoRR is sent is defined such that it excludes any Adj-RIB-Out entries added after the route-refresh started, but includes any which are changed during the process. It seems reasonable to delay any brand new reachable prefixes until after all previously announced ones have been refreshed and the EoRR sent -- if that's the intent here. Changes which occur before the refresh gets to a given entry are pretty naturally swept up by the refresh. Changes which occur after the refresh has gone past, could/should be deferred to after the EoRR ? Does it make a difference if the change is a withdraw ? (Of course MRAI may kick in here. Ah. MRAI and route-refresh, there's a topic !) >> >> I think the essence of the rule is that the EoRR should be sent once all prefixes previously advertised to the peer as reachable have been refreshed, ie announced or withdrawn (at least) once. Or, perhaps more strictly, not *before* those prefixes have *all* been announced once -- given that the EoRR will promptly bang un-advertised stuff on the head. Even more strictly perhaps: not send EoRR *before* any withdraws implied by it are required or desirable. >> >> Depending on the implementation, a given sender may or may not be able to determine the minimum set of updates required before sending EoRR. >> >> If the refresh operation takes a long time, there may be good routeing reasons to arrange for some route changes to be sent to the peer "early" -- that is to send announcements which do not contribute to the refresh, but which are important enough to warrant delaying the end of the refresh. That could be a matter for recommendation(s) in the standard. >> >> NB: given that the timing of the EoRR is tied to the state of the Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. At the beginning of the initial update, the Restarting and Receiving speakers have: >> >> Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out >> >> Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In >> >> Now suppose (bonkers or otherwise) the receiving speaker sends an RRQ part way through the initial update. The restarting speaker responds with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specification. The receiving speaker sees the EoRR, and flushes stale. Unfortunately, if the restarting speaker has not yet fully populated its Adj-RIB-Out, then many further routes will be sent before the EoR falls due -- but the receiving speaker has already flushed their tiny posteriors :-( >> >> I am coming to the view that route-refresh during a Graceful Restart initial update is a horse of a different colour altogether. >> >> [So the assumption that EoRR and EoR are triggered by the same thing was completely wrong, and I apologise for it.] >> >> Chris >> >> _______________________________________________ >> 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 thomas.mangin@exa-networks.co.uk Sun Jan 26 15:25:18 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC8C1A0175; Sun, 26 Jan 2014 15:25:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hj17JLTsRTMX; Sun, 26 Jan 2014 15:25:15 -0800 (PST) Received: from out-7.mail.exa.net.uk (out-7.mail.exa.net.uk [82.219.4.135]) by ietfa.amsl.com (Postfix) with ESMTP id EEC5F1A0171; Sun, 26 Jan 2014 15:25:11 -0800 (PST) Received: from smtp-3.mail.exa.net.uk (smtp-3.mail.exa.net.uk [82.219.5.3]) by out-7.mail.exa.net.uk (ExaSMTPD) with ESMTP id A7298A004C; Sun, 26 Jan 2014 23:25:08 +0000 (GMT) Received: from [82.219.212.37] (ptr-37.212.219.82.rev.exa.net.uk [82.219.212.37]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: thomas@mangin.com) by smtp-3.mail.exa.net.uk (ExaSMTPD) with ESMTPSA id 620866C0047; Sun, 26 Jan 2014 23:25:08 +0000 (GMT) References: <13E5680B-7295-4C05-B913-C5339993FA32@highwayman.com> <084c01cf193e$f07d3d40$d177b7c0$@highwayman.com> <52E2C8F8.1050001@cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <52E2C8F8.1050001@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (11B554a) From: Thomas Mangin Date: Sun, 26 Jan 2014 23:25:08 +0000 To: "idr-bounces@ietf.org" X-Virus-Scanned: clamav-milter 0.97.8 at out-2-2.mail.exa.net.uk X-Virus-Status: Clean Cc: "Keyur Patel \(keyupate\)" , "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 23:25:18 -0000 +1 please do not overload or change semantic. Thomas Sent from my iPad > On 24 Jan 2014, at 20:11, Enke Chen wrote: >=20 > No overloading of the existing semantics of EOR, please. There have been m= any lessons from even minimal and innocent deviation of semantics (e.g., us= ing empty UPDATE as EOR). >=20 > -- Enke >=20 >> On 1/24/14 12:00 PM, Chris Hall wrote: >> Keyur Patel wrote (on Thu 23-Jan-2014 at 23:54 +0000): >> ... >>>> I remain puzzled as to the need for EoRR. >>>>=20 >>>> Chris >>> As per RFC4724, EOR is signaled to indicate exchange of initial >>> Routing table updates. >>>=20 >>> Amongst other things (as you indicated), implementations are >>> required to defer route selection process till EOR is received. >>>=20 >>> EORR on other hand indicates exchange of subsequent Routing table >>> updates. >>>=20 >>> Both of them are enabled using different capabilities. >>>=20 >>> We believe they have different semantics and wanted to avoid >>> overloading EOR. >> So, the "initial update" (per RFC4724), graceful or otherwise, is >> intended to be orthogonal to route-refresh triggered by either >> route-refresh request (RRQ) or BoRR. >>=20 >> Hence, any route-refresh during the "initial update" (however bonkers) >> would be treated as being nested inside that initial update -- so >> start and end before the EoR. >>=20 >> The straightforward approach to BoRR during "initial update" is for >> the sender (of the BoRR) to rewind and then keep going until it has >> sent everything there is to send. The EoRR and EoR are then triggered >> simultaneously but sent in that order. The receiver of the BoRR >> (re-)marks everything stale (not flushing existing stale and not >> restarting any stale-timer, presumably) and proceeds until it sees >> EoRR and then EoR (and, possibly, further BoRR before the EoRR). This >> approach implicitly uses the same stale marking and flushing, and the >> same stale-timer as (any) Graceful Restart -- making the EoRR, >> largely, redundant in this state. >>=20 >> One could argue that, during initial update, after a BoRR the sender >> could/should only repeat the routes which have been sent up to that >> point, and then issue the EoRR. The initial update would then proceed >> from where it left off. This is fully consistent with treating >> "initial update" and route-refresh as orthogonal, but complicates >> things, to no obvious advantage. If such a "clever" approach were >> deemed to be a useful implementation option, the specification needs >> to provide for the combinations of "clever" and "straightforward" >> senders and receivers. >>=20 >> It seems to me that initial update interacts with enhanced >> route-refresh, so they aren't entirely orthogonal, and the interaction >> could do with being defined. >>=20 >> Yet another option would be to ban BoRR in initial update state, or >> define it to implicitly terminate that state (BoRR =3D> EoR) (it's not >> clear to me how useful BoRR is in initial update state). And, >> Enhanced Route-Refresh could be suppressed in initial update state, so >> that RRQ operates as now (for what that's worth). These steps >> eliminate the whole BoRR/EoRR during initial update kerfuffle >> altogether. >>=20 >> Finally, perhaps the conclusion is that during initial update, BoRR >> really means "I am restarting the initial update"... and perhaps BoRR >> should not be overloaded here ? >>=20 >> Chris >>=20 >> PS: I hear what you say, but I cannot help feeling that EoR could be >> enabled for its current semantics (when in "initial update" state) by >> the Graceful Restart capability, and enabled for EoRR semantics (when >> not in "initial update" state) by the Enhanced Route-Refresh >> capability. There would then be one less message type to worry about >> :-) And the meaning of the combined EoR/EoRR message is explicitly >> dependent on the "initial update" state. >>=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 From thomas.mangin@exa-networks.co.uk Sun Jan 26 15:39:44 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF60C1A0169; Sun, 26 Jan 2014 15:39:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNKwh5wXE5qq; Sun, 26 Jan 2014 15:39:41 -0800 (PST) Received: from out-7.mail.exa.net.uk (out-7.mail.exa.net.uk [82.219.4.135]) by ietfa.amsl.com (Postfix) with ESMTP id 265C51A0168; Sun, 26 Jan 2014 15:39:40 -0800 (PST) Received: from smtp-3.mail.exa.net.uk (smtp-3.mail.exa.net.uk [82.219.5.3]) by out-7.mail.exa.net.uk (ExaSMTPD) with ESMTP id AFE18A004C; Sun, 26 Jan 2014 23:39:38 +0000 (GMT) Received: from [82.219.212.37] (ptr-37.212.219.82.rev.exa.net.uk [82.219.212.37]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: thomas@mangin.com) by smtp-3.mail.exa.net.uk (ExaSMTPD) with ESMTPSA id 759156C0047; Sun, 26 Jan 2014 23:39:38 +0000 (GMT) References: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F54ED5@eusaamb109.ericsson.se> <10eca092172d443380eccf2e8548f2a9@BLUPR09MB053.namprd09.prod.outlook.com> <98FB84F8-96B2-4D7B-8FF0-0A3DE4D90465@ericsson.com> <07a101cf1861$7cf46700$76dd3500$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F55B8C@eusaamb109.ericsson.se> <07c701cf1878$2f67aee0$8e370ca0$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F55E37@eusaamb109.ericsson.se> <13E5680B-7295-4C05-B913-C5339993FA32@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F56346@eusaamb109.ericsson.se> <085301cf1942$0bbdae70$23390b50$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F577F9@eusaamb109.ericsson.se> <08e201cf1a03$8efad120$acf07360$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F6716D@eusaamb109.ericsson.se> Mime-Version: 1.0 (1.0) In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F6716D@eusaamb109.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <8E2ED3B6-A49B-4634-A7C0-32781A854EC9@exa-networks.co.uk> X-Mailer: iPad Mail (11B554a) From: Thomas Mangin Date: Sun, 26 Jan 2014 23:39:36 +0000 To: "idr-bounces@ietf.org" X-Virus-Scanned: clamav-milter 0.97.8 at out-2-2.mail.exa.net.uk X-Virus-Status: Clean Cc: "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 23:39:44 -0000 Damn, time to practice then :) Joke apart, I agree with this post. The feature should not be used ( and ign= ored ) until the initial route exchange has been completed. If the session drops, I would expect the router to cancel any RR which was o= ngoing as the AdjRIBOut is going to be retransmitted anyway. Thomas Sent from my iPad > On 25 Jan 2014, at 19:48, Jakob Heitz wrote: >=20 > RFCs are written for coders "practiced" in the art". > If anyone sends an EoRR before the adj-RIB-out is fully populated, then it= 's a BUG. > This does not need to be said. >=20 > Personally, I believe a route refresh request should not be honored until G= R is complete. > Also, I don't believe a timer for the receipt of EoRR is necessary, becaus= e the EoRR is guaranteed. > Guaranteed means "unless the session drops first". > -- >=20 > Jakob Heitz. >=20 > ________________________________________ > From: Chris Hall [chris.hall@highwayman.com] > Sent: Saturday, 25 January 2014 11:27 AM > To: idr@ietf.org > Cc: Jakob Heitz > Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh >=20 > Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): > ... >> Silence means don't do it. >=20 > Hmmm.... as a principle I'm more comfortable with "that which isn't > prohibited is permitted".... >=20 >> You would definitely NOT want BoRR to flush old stales. >=20 > ....but, given the definite requirement, and given that the current > precedent for "marking stale" does flush old stale, then a few words > for the avoidance of doubt ? >=20 >> Restarting the timer might be a good idea. >=20 > I dunno... a route which remains stale for "a long time" is, of > course, a candidate for being withdrawn: so having started a timer the > first time things are set stale, I would avoid extending that -- at > least for Graceful Restart, where the whole withdraw thing has been > "on-hold" since the last session failed. For route-refresh I guess > there's more of a presumption that stale routes will be refreshed > sooner or later, and in the meantime they remain good. So if the > route-refresh is (repeatedly) restarted for some reason, perhaps it is > more reasonable to extend the flush deadline -- but avoid doing this > indefinitely ? >=20 > FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I have > built in Quagga prioritise route changes (pending changes and any that > occur during the refresh) over refresh updates. This makes it more > likely that remaining stale routes are still good. But the other end > cannot know that. >=20 > The paragraph in the draft discussing the "entire Adj-RIB-Out" defines > that to be the entries present "at the start of the route refresh > operation", and observes that these comprise both reachable and > unreachable routes. [An "of" after "comprise" sets teeth on edge, > BTW.] I'm really not sure what this paragraph is trying to tell me. > The reference to unreachable routes appears to suggest that pending > withdraws should be sent as part of the refresh -- so not left to the > EoRR to implement at the end. The point at which the EoRR is sent is > defined such that it excludes any Adj-RIB-Out entries added after the > route-refresh started, but includes any which are changed during the > process. It seems reasonable to delay any brand new reachable > prefixes until after all previously announced ones have been refreshed > and the EoRR sent -- if that's the intent here. Changes which occur > before the refresh gets to a given entry are pretty naturally swept up > by the refresh. Changes which occur after the refresh has gone past, > could/should be deferred to after the EoRR ? Does it make a > difference if the change is a withdraw ? (Of course MRAI may kick in > here. Ah. MRAI and route-refresh, there's a topic !) >=20 > I think the essence of the rule is that the EoRR should be sent once > all prefixes previously advertised to the peer as reachable have been > refreshed, ie announced or withdrawn (at least) once. Or, perhaps > more strictly, not *before* those prefixes have *all* been announced > once -- given that the EoRR will promptly bang un-advertised stuff on > the head. Even more strictly perhaps: not send EoRR *before* any > withdraws implied by it are required or desirable. >=20 > Depending on the implementation, a given sender may or may not be able > to determine the minimum set of updates required before sending EoRR. >=20 > If the refresh operation takes a long time, there may be good routeing > reasons to arrange for some route changes to be sent to the peer > "early" -- that is to send announcements which do not contribute to > the refresh, but which are important enough to warrant delaying the > end of the refresh. That could be a matter for recommendation(s) in > the standard. >=20 > NB: given that the timing of the EoRR is tied to the state of the > Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. At > the beginning of the initial update, the Restarting and Receiving > speakers have: >=20 > Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out >=20 > Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In >=20 > Now suppose (bonkers or otherwise) the receiving speaker sends an RRQ > part way through the initial update. The restarting speaker responds > with BoRR, everything in its Adj-RIB-Out, and EoRR -- per > specification. The receiving speaker sees the EoRR, and flushes > stale. Unfortunately, if the restarting speaker has not yet fully > populated its Adj-RIB-Out, then many further routes will be sent > before the EoR falls due -- but the receiving speaker has already > flushed their tiny posteriors :-( >=20 > I am coming to the view that route-refresh during a Graceful Restart > initial update is a horse of a different colour altogether. >=20 > [So the assumption that EoRR and EoR are triggered by the same thing > was completely wrong, and I apologise for it.] >=20 > Chris >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 From internet-drafts@ietf.org Mon Jan 27 06:40:22 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08B171A022F; Mon, 27 Jan 2014 06:40:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkrI6ycetXmX; Mon, 27 Jan 2014 06:40:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BBADF1A013F; Mon, 27 Jan 2014 06:40:20 -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: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140127144020.18998.16993.idtracker@ietfa.amsl.com> Date: Mon, 27 Jan 2014 06:40:20 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 14:40:22 -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 : Extended Message support for BGP Authors : Keyur Patel Dave Ward Randy Bush Filename : draft-ietf-idr-bgp-extended-messages-07.txt Pages : 4 Date : 2014-01-27 Abstract: The BGP specification mandates a maximum BGP message size of 4096 octets. As BGP is extended to support newer AFI/SAFIs, there is a need to extend the maximum message size beyond 4096 octets. This document updates [RFC4271] by providing an extension to BGP to extend its current message size from 4096 octets to 65535 octets. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-bgp-extended-messages-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jan 27 10:23:58 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D41B1A028B; Mon, 27 Jan 2014 10:23:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iE2siZqe3LUr; Mon, 27 Jan 2014 10:23:53 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 745531A024F; Mon, 27 Jan 2014 10:23:53 -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: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140127182352.32526.86857.idtracker@ietfa.amsl.com> Date: Mon, 27 Jan 2014 10:23:52 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-add-paths-guidelines-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 18:23:58 -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 Path= s in IBGP Authors : Jim Uttaro Pierre Francois Roberto Fragassi Adam Simpson Keyur Patel Pradosh Mohapatra Filename : draft-ietf-idr-add-paths-guidelines-06.txt Pages : 24 Date : 2014-01-27 Abstract: Add-Paths is a BGP enhancement that allows a BGP router to advertise multiple distinct paths for the same prefix/NLRI. This provides a number of potential benefits, including reduced routing churn, faster convergence and better loadsharing. This document provides recommendations to implementers of Add-Paths so that network operators have the tools needed to address their specific applications and to manage the scalability impact of Add- Paths. A router implementing Add-Paths may learn many paths for a prefix and must decide which of these to advertise to peers. This document analyses different algorithms for making this selection and provides recommendations based on the target application. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-add-paths-guidelines/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-add-paths-guidelines-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-add-paths-guidelines-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From thomas.mangin@exa-networks.co.uk Mon Jan 27 11:59:24 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9B91A029F for ; Mon, 27 Jan 2014 11:59:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IA-zxSKoTuqz for ; Mon, 27 Jan 2014 11:59:22 -0800 (PST) Received: from out-7.mail.exa.net.uk (out-7.mail.exa.net.uk [82.219.4.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2A41A001E for ; Mon, 27 Jan 2014 11:59:21 -0800 (PST) Received: from smtp-4.mail.exa.net.uk (smtp-4.mail.exa.net.uk [82.219.5.4]) by out-7.mail.exa.net.uk (ExaSMTPD) with ESMTP id 5E9DEA004D for ; Mon, 27 Jan 2014 19:59:19 +0000 (GMT) Received: from [192.168.1.16] (ptr-1.212.219.82.rev.exa.net.uk [82.219.212.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: thomas@mangin.com) by smtp-4.mail.exa.net.uk (ExaSMTPD) with ESMTPSA id 18E594008C for ; Mon, 27 Jan 2014 19:59:19 +0000 (GMT) From: Thomas Mangin Content-Type: multipart/signed; boundary="Apple-Mail=_BDF465F0-30B2-4CA9-822E-521849825F30"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: <6A7AA3B6-5D83-48F0-A438-8F95720FFC7F@exa-networks.co.uk> Date: Mon, 27 Jan 2014 19:59:18 +0000 To: idr wg Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) X-Virus-Scanned: clamav-milter 0.97.8 at out-2-2.mail.exa.net.uk X-Virus-Status: Clean Subject: [Idr] RFC 5575: broken implementation X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 19:59:24 -0000 --Apple-Mail=_BDF465F0-30B2-4CA9-822E-521849825F30 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, One of ExaBGP's user recently found that JunOS implementation does not = respect RFC 5575 section 7[1] which says that the traffic rate is = expressed in BYTES per seconds. JunOS parses the packet data received as = BITS per seconds. On notification, Juniper's TAC updated their = documentation from Bps to bps .. [2] so it seems unlikely that a fix is = pending ... I am wondering if this behaviour is consistent with other vendors ( = AFAIK only ALU has implemented it but I have no way to test how they = interpret the data ). Should the behaviour be consistently BITS per seconds. I am wondering if = it would be better to update the RFC and not the implementations ? Any help sorting out this issue would be most welcome.=20 Sincerely, Thomas [1] http://tools.ietf.org/html/rfc5575#section-7 [2] = http://www.juniper.net/techpubs/en_US/junos12.1/topics/concept/flow-routes= -understanding.html --Apple-Mail=_BDF465F0-30B2-4CA9-822E-521849825F30 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlLmupYACgkQA/52wvuLgaESXwCgy6ZsvMFtRFKOllyU36BNchmb tswAoLAHIa2DbuQCPP2vWO1s7sQknVGD =40yO -----END PGP SIGNATURE----- --Apple-Mail=_BDF465F0-30B2-4CA9-822E-521849825F30-- From jhaas@slice.pfrc.org Mon Jan 27 12:38:30 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 715D11A02DC for ; Mon, 27 Jan 2014 12:38:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUCULvtRr2vQ for ; Mon, 27 Jan 2014 12:38:28 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A7E8A1A029E for ; Mon, 27 Jan 2014 12:38:28 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 5AB2BC1A4; Mon, 27 Jan 2014 15:38:26 -0500 (EST) Date: Mon, 27 Jan 2014 15:38:26 -0500 From: Jeffrey Haas To: Thomas Mangin Message-ID: <20140127203826.GC11981@pfrc> References: <6A7AA3B6-5D83-48F0-A438-8F95720FFC7F@exa-networks.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6A7AA3B6-5D83-48F0-A438-8F95720FFC7F@exa-networks.co.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: idr wg Subject: Re: [Idr] RFC 5575: broken implementation X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 20:38:30 -0000 [I generally try to avoid speaking for the employer outside of standards from this address, but IDR usually doesn't talk about vendor bugs. :-) ] On Mon, Jan 27, 2014 at 07:59:18PM +0000, Thomas Mangin wrote: > One of ExaBGP's user recently found that JunOS implementation does not respect RFC 5575 section 7[1] which says that the traffic rate is expressed in BYTES per seconds. JunOS parses the packet data received as BITS per seconds. On notification, Juniper's TAC updated their documentation from Bps to bps .. [2] so it seems unlikely that a fix is pending ... Already fixed as PR 864496. I unfortunately don't have the cycles to hunt down the public face of this bug. > I am wondering if this behaviour is consistent with other vendors ( AFAIK only ALU has implemented it but I have no way to test how they interpret the data ). > Should the behaviour be consistently BITS per seconds. I am wondering if it would be better to update the RFC and not the implementations ? This is probably the more interesting story long term. Much of the point of interoperable deployments is that these silly bugs don't morph into a fight between updating the code vs. the specs. (Long time readers of IDR will recall the code point issues for BGP Confederation segments. ;-) Where such things become ugly is when you have a mixed deployment of things with the bug fixes vs. not. Whether to give fixes knobs often comes down on which big customer is annoyed by the change. > Any help sorting out this issue would be most welcome. Get your JTAC person to find you a version that covers PR 864496. Do the right thing. In the absence of the fix, realize there's a bug. Deal accordingly. -- Jeff From keyupate@cisco.com Tue Jan 28 11:50:49 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8599B1A037C; Tue, 28 Jan 2014 11:50:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Hds1-_w9mMG; Tue, 28 Jan 2014 11:50:46 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3DF1A0378; Tue, 28 Jan 2014 11:50:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6750; q=dns/txt; s=iport; t=1390938644; x=1392148244; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ocSGn/mCeHC79n4PcAywTDNfIvAnmpFxc0m9iNNP1jw=; b=O3XYKQUANx1kywCog26dCR44t97QRhlzTeLeLYB7rW9Nat1mq1+4yZBB n8E5HPeJva43gnAq/k0hJ+w6++yYaZnr4t6HVLxSn+AkRiyeH9bepoEw2 7jfaGOmoCPOuHQnxIM8noTbjKnOb83t2KK1bjHTvdlJbyYgbdwRJzZqkX k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAKsJ6FKtJXG9/2dsb2JhbABagww4VrxmgREWdIIlAQEBBAEBATc0CxIBCBEEAQEBHjcLHQgCBAENBYgFDakHoHETBI5/B4Q4AQOYKJIfgy2CKg X-IronPort-AV: E=Sophos;i="4.95,737,1384300800"; d="scan'208";a="300303436" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 28 Jan 2014 19:50:43 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0SJohYU031975 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Jan 2014 19:50:43 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.228]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Tue, 28 Jan 2014 13:50:43 -0600 From: "Keyur Patel (keyupate)" To: Thomas Mangin , "idr-bounces@ietf.org" Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPHGI6keX0Ff7T2kONFJ6OHVSLvw== Date: Tue, 28 Jan 2014 19:50:42 +0000 Message-ID: In-Reply-To: <8E2ED3B6-A49B-4634-A7C0-32781A854EC9@exa-networks.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [128.107.163.31] Content-Type: text/plain; charset="us-ascii" Content-ID: <1648A688CD4B48459049E36C502336BE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 19:50:49 -0000 Hi Jacob, Thomas, Am ok with implementations delaying the servicing of route refresh request. Enke's suggested text addresses the concern. Best Regards, Keyur On 1/26/14 3:39 PM, "Thomas Mangin" wrote: >Damn, time to practice then :) > >Joke apart, I agree with this post. The feature should not be used ( and >ignored ) until the initial route exchange has been completed. > >If the session drops, I would expect the router to cancel any RR which >was ongoing as the AdjRIBOut is going to be retransmitted anyway. > >Thomas > >Sent from my iPad > >> On 25 Jan 2014, at 19:48, Jakob Heitz wrote: >>=20 >> RFCs are written for coders "practiced" in the art". >> If anyone sends an EoRR before the adj-RIB-out is fully populated, then >>it's a BUG. >> This does not need to be said. >>=20 >> Personally, I believe a route refresh request should not be honored >>until GR is complete. >> Also, I don't believe a timer for the receipt of EoRR is necessary, >>because the EoRR is guaranteed. >> Guaranteed means "unless the session drops first". >> -- >>=20 >> Jakob Heitz. >>=20 >> ________________________________________ >> From: Chris Hall [chris.hall@highwayman.com] >> Sent: Saturday, 25 January 2014 11:27 AM >> To: idr@ietf.org >> Cc: Jakob Heitz >> Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh >>=20 >> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): >> ... >>> Silence means don't do it. >>=20 >> Hmmm.... as a principle I'm more comfortable with "that which isn't >> prohibited is permitted".... >>=20 >>> You would definitely NOT want BoRR to flush old stales. >>=20 >> ....but, given the definite requirement, and given that the current >> precedent for "marking stale" does flush old stale, then a few words >> for the avoidance of doubt ? >>=20 >>> Restarting the timer might be a good idea. >>=20 >> I dunno... a route which remains stale for "a long time" is, of >> course, a candidate for being withdrawn: so having started a timer the >> first time things are set stale, I would avoid extending that -- at >> least for Graceful Restart, where the whole withdraw thing has been >> "on-hold" since the last session failed. For route-refresh I guess >> there's more of a presumption that stale routes will be refreshed >> sooner or later, and in the meantime they remain good. So if the >> route-refresh is (repeatedly) restarted for some reason, perhaps it is >> more reasonable to extend the flush deadline -- but avoid doing this >> indefinitely ? >>=20 >> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I have >> built in Quagga prioritise route changes (pending changes and any that >> occur during the refresh) over refresh updates. This makes it more >> likely that remaining stale routes are still good. But the other end >> cannot know that. >>=20 >> The paragraph in the draft discussing the "entire Adj-RIB-Out" defines >> that to be the entries present "at the start of the route refresh >> operation", and observes that these comprise both reachable and >> unreachable routes. [An "of" after "comprise" sets teeth on edge, >> BTW.] I'm really not sure what this paragraph is trying to tell me. >> The reference to unreachable routes appears to suggest that pending >> withdraws should be sent as part of the refresh -- so not left to the >> EoRR to implement at the end. The point at which the EoRR is sent is >> defined such that it excludes any Adj-RIB-Out entries added after the >> route-refresh started, but includes any which are changed during the >> process. It seems reasonable to delay any brand new reachable >> prefixes until after all previously announced ones have been refreshed >> and the EoRR sent -- if that's the intent here. Changes which occur >> before the refresh gets to a given entry are pretty naturally swept up >> by the refresh. Changes which occur after the refresh has gone past, >> could/should be deferred to after the EoRR ? Does it make a >> difference if the change is a withdraw ? (Of course MRAI may kick in >> here. Ah. MRAI and route-refresh, there's a topic !) >>=20 >> I think the essence of the rule is that the EoRR should be sent once >> all prefixes previously advertised to the peer as reachable have been >> refreshed, ie announced or withdrawn (at least) once. Or, perhaps >> more strictly, not *before* those prefixes have *all* been announced >> once -- given that the EoRR will promptly bang un-advertised stuff on >> the head. Even more strictly perhaps: not send EoRR *before* any >> withdraws implied by it are required or desirable. >>=20 >> Depending on the implementation, a given sender may or may not be able >> to determine the minimum set of updates required before sending EoRR. >>=20 >> If the refresh operation takes a long time, there may be good routeing >> reasons to arrange for some route changes to be sent to the peer >> "early" -- that is to send announcements which do not contribute to >> the refresh, but which are important enough to warrant delaying the >> end of the refresh. That could be a matter for recommendation(s) in >> the standard. >>=20 >> NB: given that the timing of the EoRR is tied to the state of the >> Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. At >> the beginning of the initial update, the Restarting and Receiving >> speakers have: >>=20 >> Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out >>=20 >> Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In >>=20 >> Now suppose (bonkers or otherwise) the receiving speaker sends an RRQ >> part way through the initial update. The restarting speaker responds >> with BoRR, everything in its Adj-RIB-Out, and EoRR -- per >> specification. The receiving speaker sees the EoRR, and flushes >> stale. Unfortunately, if the restarting speaker has not yet fully >> populated its Adj-RIB-Out, then many further routes will be sent >> before the EoR falls due -- but the receiving speaker has already >> flushed their tiny posteriors :-( >>=20 >> I am coming to the view that route-refresh during a Graceful Restart >> initial update is a horse of a different colour altogether. >>=20 >> [So the assumption that EoRR and EoR are triggered by the same thing >> was completely wrong, and I apologise for it.] >>=20 >> Chris >>=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 jakob.heitz@ericsson.com Tue Jan 28 12:06:58 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0C21A03D1; Tue, 28 Jan 2014 12:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iQmLHRh9O6M; Tue, 28 Jan 2014 12:06:56 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB061A03B7; Tue, 28 Jan 2014 12:06:56 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-3e-52e80dda47f2 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id DF.11.12743.ADD08E25; Tue, 28 Jan 2014 21:06:50 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0387.000; Tue, 28 Jan 2014 15:06:52 -0500 From: Jakob Heitz To: "Keyur Patel (keyupate)" , Thomas Mangin , "idr-bounces@ietf.org" Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPF5KdKHMolEg8TF26AxOKep0T6JqRMOhAgAGfMAD//7gu+4AAX1gA//+1BTCAAHhgAP//sQGgAA5+ToAABygAoAAmsOcAAAoIr7AAJlf4AP//r6/0gAIo+ACAAuS2AIAAU2KQ Date: Tue, 28 Jan 2014 20:06:52 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F6E1AF@eusaamb109.ericsson.se> References: <8E2ED3B6-A49B-4634-A7C0-32781A854EC9@exa-networks.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyuXRPgu4t3hdBBoteS1nM2Tid1eLV7WdM Fo1bz7NZTNq2mtWBxWPK742sHv1nNzN5LFnykymAOYrLJiU1J7MstUjfLoEr4/ebTtaCF1YV z+5PZG5g/KnfxcjJISFgIvFi5lIWCFtM4sK99WxdjFwcQgJHGCUObmtngXCWM0ps/zqDCaSK TUBH4tv1LmaQhIjANEaJzsYNYAlmAUWJi387wGxhATeJuy2fwWwRAXeJlh+TEBqWL1nHCpJg EVCVWH10FdhuXgFfiZO7f7F3MXIArcuWuP21GiTMKWAgMfPBFLByRqDzvp9aA7VLXOLWk/lM EGcLSCzZc54ZwhaVePn4HyuErSQxaek5Voh6HYkFuz+xQdjaEssWvmaGWCsocXLmE5YJjGKz kIydhaRlFpKWWUhaFjCyrGLkKC1OLctNNzLYxAiMo2MSbLo7GPe8tDzEKM3BoiTO++Wtc5CQ QHpiSWp2ampBalF8UWlOavEhRiYOTqkGxtwfmwvPTo/9l6Wb81xhvp8GU0/Gql9/ehdcnfCT 8UMqk8m893dk0/b/CWLqKzz2zmvhumVbHTm7haOLb/X+mZPVt+9w9uws329f250aVnvfSZzp OPlfqPVyISuTCM0vYjc7N3KdOe3qJr/sg4xGXPXldfJ9q2TjJ7NyrXkesPLatsAN9RfEY5VY ijMSDbWYi4oTAWonIrtxAgAA Cc: "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 20:06:59 -0000 Enke's text allows the order: BoRR, EoR, EoRR. Could we change Enke's text from "it MUST NOT send an EoRR" to=20 "it MUST NOT send an BoRR" Thanks, Jakob. -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Keyur Patel (keyupate) Sent: Tuesday, January 28, 2014 11:51 AM To: Thomas Mangin; idr-bounces@ietf.org Cc: idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Jacob, Thomas, Am ok with implementations delaying the servicing of route refresh request.= Enke's suggested text addresses the concern. Best Regards, Keyur On 1/26/14 3:39 PM, "Thomas Mangin" wrote: >Damn, time to practice then :) > >Joke apart, I agree with this post. The feature should not be used (=20 >and ignored ) until the initial route exchange has been completed. > >If the session drops, I would expect the router to cancel any RR which=20 >was ongoing as the AdjRIBOut is going to be retransmitted anyway. > >Thomas > >Sent from my iPad > >> On 25 Jan 2014, at 19:48, Jakob Heitz wrote: >>=20 >> RFCs are written for coders "practiced" in the art". >> If anyone sends an EoRR before the adj-RIB-out is fully populated,=20 >>then it's a BUG. >> This does not need to be said. >>=20 >> Personally, I believe a route refresh request should not be honored=20 >>until GR is complete. >> Also, I don't believe a timer for the receipt of EoRR is necessary,=20 >>because the EoRR is guaranteed. >> Guaranteed means "unless the session drops first". >> -- >>=20 >> Jakob Heitz. >>=20 >> ________________________________________ >> From: Chris Hall [chris.hall@highwayman.com] >> Sent: Saturday, 25 January 2014 11:27 AM >> To: idr@ietf.org >> Cc: Jakob Heitz >> Subject: RE: [Idr] WG LC for=20 >> draft-ietf-idr-bgp-enhanced-route-refresh >>=20 >> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): >> ... >>> Silence means don't do it. >>=20 >> Hmmm.... as a principle I'm more comfortable with "that which isn't=20 >> prohibited is permitted".... >>=20 >>> You would definitely NOT want BoRR to flush old stales. >>=20 >> ....but, given the definite requirement, and given that the current=20 >> precedent for "marking stale" does flush old stale, then a few words=20 >> for the avoidance of doubt ? >>=20 >>> Restarting the timer might be a good idea. >>=20 >> I dunno... a route which remains stale for "a long time" is, of=20 >> course, a candidate for being withdrawn: so having started a timer=20 >> the first time things are set stale, I would avoid extending that --=20 >> at least for Graceful Restart, where the whole withdraw thing has=20 >> been "on-hold" since the last session failed. For route-refresh I=20 >> guess there's more of a presumption that stale routes will be=20 >> refreshed sooner or later, and in the meantime they remain good. So=20 >> if the route-refresh is (repeatedly) restarted for some reason,=20 >> perhaps it is more reasonable to extend the flush deadline -- but=20 >> avoid doing this indefinitely ? >>=20 >> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I have=20 >> built in Quagga prioritise route changes (pending changes and any=20 >> that occur during the refresh) over refresh updates. This makes it=20 >> more likely that remaining stale routes are still good. But the=20 >> other end cannot know that. >>=20 >> The paragraph in the draft discussing the "entire Adj-RIB-Out"=20 >> defines that to be the entries present "at the start of the route=20 >> refresh operation", and observes that these comprise both reachable=20 >> and unreachable routes. [An "of" after "comprise" sets teeth on=20 >> edge, BTW.] I'm really not sure what this paragraph is trying to tell m= e. >> The reference to unreachable routes appears to suggest that pending=20 >> withdraws should be sent as part of the refresh -- so not left to the=20 >> EoRR to implement at the end. The point at which the EoRR is sent is=20 >> defined such that it excludes any Adj-RIB-Out entries added after the=20 >> route-refresh started, but includes any which are changed during the=20 >> process. It seems reasonable to delay any brand new reachable=20 >> prefixes until after all previously announced ones have been=20 >> refreshed and the EoRR sent -- if that's the intent here. Changes=20 >> which occur before the refresh gets to a given entry are pretty=20 >> naturally swept up by the refresh. Changes which occur after the=20 >> refresh has gone past, could/should be deferred to after the EoRR ? =20 >> Does it make a difference if the change is a withdraw ? (Of course=20 >> MRAI may kick in here. Ah. MRAI and route-refresh, there's a topic=20 >> !) >>=20 >> I think the essence of the rule is that the EoRR should be sent once=20 >> all prefixes previously advertised to the peer as reachable have been=20 >> refreshed, ie announced or withdrawn (at least) once. Or, perhaps=20 >> more strictly, not *before* those prefixes have *all* been announced=20 >> once -- given that the EoRR will promptly bang un-advertised stuff on=20 >> the head. Even more strictly perhaps: not send EoRR *before* any=20 >> withdraws implied by it are required or desirable. >>=20 >> Depending on the implementation, a given sender may or may not be=20 >> able to determine the minimum set of updates required before sending EoR= R. >>=20 >> If the refresh operation takes a long time, there may be good=20 >> routeing reasons to arrange for some route changes to be sent to the=20 >> peer "early" -- that is to send announcements which do not contribute=20 >> to the refresh, but which are important enough to warrant delaying=20 >> the end of the refresh. That could be a matter for recommendation(s)=20 >> in the standard. >>=20 >> NB: given that the timing of the EoRR is tied to the state of the=20 >> Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. At=20 >> the beginning of the initial update, the Restarting and Receiving=20 >> speakers have: >>=20 >> Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out >>=20 >> Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In >>=20 >> Now suppose (bonkers or otherwise) the receiving speaker sends an RRQ=20 >> part way through the initial update. The restarting speaker responds=20 >> with BoRR, everything in its Adj-RIB-Out, and EoRR -- per=20 >> specification. The receiving speaker sees the EoRR, and flushes=20 >> stale. Unfortunately, if the restarting speaker has not yet fully=20 >> populated its Adj-RIB-Out, then many further routes will be sent=20 >> before the EoR falls due -- but the receiving speaker has already=20 >> flushed their tiny posteriors :-( >>=20 >> I am coming to the view that route-refresh during a Graceful Restart=20 >> initial update is a horse of a different colour altogether. >>=20 >> [So the assumption that EoRR and EoR are triggered by the same thing=20 >> was completely wrong, and I apologise for it.] >>=20 >> Chris >>=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 _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From keyupate@cisco.com Tue Jan 28 12:17:04 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED05F1A039E; Tue, 28 Jan 2014 12:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id riBLDzOMDyru; Tue, 28 Jan 2014 12:17:00 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id A25D41A028B; Tue, 28 Jan 2014 12:17:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7829; q=dns/txt; s=iport; t=1390940218; x=1392149818; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=MS1o7O6SOMlTIy+iD9ul7/amI/Du059OEfv313Jwp20=; b=dRel8Il6NmVz6/yN3atR6Dn6QxPGPhQkq4fRAc/lUdrwc4d/3Jskcvb1 THpTu+nVP1hmBEbr/pATIfEnmMt6exZ+a1S5IInGCnq8rUrziOXpxZSv2 6+1rNHVtpz8qZ75O7gT5wd/F45f8hjHXNdYcpk9LZh7O2d1yqqRGLihRB o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAIAP6FKtJXG9/2dsb2JhbABagww4VrxrgREWdIIlAQEBBAEBATc0CwwGAQgRBAEBAR4JLgsUCQgCBAENBYgFDakLoHATBI5/BwaEMgEDlECDaJIfgy2BaAc7 X-IronPort-AV: E=Sophos;i="4.95,737,1384300800"; d="scan'208";a="300106248" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 28 Jan 2014 20:16:57 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0SKGv1a029382 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Jan 2014 20:16:57 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.228]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Tue, 28 Jan 2014 14:16:57 -0600 From: "Keyur Patel (keyupate)" To: Jakob Heitz , Thomas Mangin , "idr-bounces@ietf.org" Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPHGXkkeX0Ff7T2kONFJ6OHVSLvw== Date: Tue, 28 Jan 2014 20:16:57 +0000 Message-ID: In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F6E1AF@eusaamb109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [128.107.163.31] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 20:17:04 -0000 The order: BoRR, EoR, EoRR lets an implementation do both, merge route refresh reply with an initial table announcement or delay the route refresh replies. As long as EoR is sent before EoRR there should be no issue right? Regards, Keyur On 1/28/14 12:06 PM, "Jakob Heitz" wrote: >Enke's text allows the order: BoRR, EoR, EoRR. > >Could we change Enke's text from >"it MUST NOT send an EoRR" to >"it MUST NOT send an BoRR" > >Thanks, >Jakob. > >-----Original Message----- >From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Keyur Patel >(keyupate) >Sent: Tuesday, January 28, 2014 11:51 AM >To: Thomas Mangin; idr-bounces@ietf.org >Cc: idr@ietf.org >Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh > >Hi Jacob, Thomas, > >Am ok with implementations delaying the servicing of route refresh >request. Enke's suggested text addresses the concern. > >Best Regards, >Keyur > >On 1/26/14 3:39 PM, "Thomas Mangin" >wrote: > >>Damn, time to practice then :) >> >>Joke apart, I agree with this post. The feature should not be used ( >>and ignored ) until the initial route exchange has been completed. >> >>If the session drops, I would expect the router to cancel any RR which >>was ongoing as the AdjRIBOut is going to be retransmitted anyway. >> >>Thomas >> >>Sent from my iPad >> >>> On 25 Jan 2014, at 19:48, Jakob Heitz wrote: >>>=20 >>> RFCs are written for coders "practiced" in the art". >>> If anyone sends an EoRR before the adj-RIB-out is fully populated, >>>then it's a BUG. >>> This does not need to be said. >>>=20 >>> Personally, I believe a route refresh request should not be honored >>>until GR is complete. >>> Also, I don't believe a timer for the receipt of EoRR is necessary, >>>because the EoRR is guaranteed. >>> Guaranteed means "unless the session drops first". >>> -- >>>=20 >>> Jakob Heitz. >>>=20 >>> ________________________________________ >>> From: Chris Hall [chris.hall@highwayman.com] >>> Sent: Saturday, 25 January 2014 11:27 AM >>> To: idr@ietf.org >>> Cc: Jakob Heitz >>> Subject: RE: [Idr] WG LC for >>> draft-ietf-idr-bgp-enhanced-route-refresh >>>=20 >>> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): >>> ... >>>> Silence means don't do it. >>>=20 >>> Hmmm.... as a principle I'm more comfortable with "that which isn't >>> prohibited is permitted".... >>>=20 >>>> You would definitely NOT want BoRR to flush old stales. >>>=20 >>> ....but, given the definite requirement, and given that the current >>> precedent for "marking stale" does flush old stale, then a few words >>> for the avoidance of doubt ? >>>=20 >>>> Restarting the timer might be a good idea. >>>=20 >>> I dunno... a route which remains stale for "a long time" is, of >>> course, a candidate for being withdrawn: so having started a timer >>> the first time things are set stale, I would avoid extending that -- >>> at least for Graceful Restart, where the whole withdraw thing has >>> been "on-hold" since the last session failed. For route-refresh I >>> guess there's more of a presumption that stale routes will be >>> refreshed sooner or later, and in the meantime they remain good. So >>> if the route-refresh is (repeatedly) restarted for some reason, >>> perhaps it is more reasonable to extend the flush deadline -- but >>> avoid doing this indefinitely ? >>>=20 >>> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I have >>> built in Quagga prioritise route changes (pending changes and any >>> that occur during the refresh) over refresh updates. This makes it >>> more likely that remaining stale routes are still good. But the >>> other end cannot know that. >>>=20 >>> The paragraph in the draft discussing the "entire Adj-RIB-Out" >>> defines that to be the entries present "at the start of the route >>> refresh operation", and observes that these comprise both reachable >>> and unreachable routes. [An "of" after "comprise" sets teeth on >>> edge, BTW.] I'm really not sure what this paragraph is trying to tell >>>me. >>> The reference to unreachable routes appears to suggest that pending >>> withdraws should be sent as part of the refresh -- so not left to the >>> EoRR to implement at the end. The point at which the EoRR is sent is >>> defined such that it excludes any Adj-RIB-Out entries added after the >>> route-refresh started, but includes any which are changed during the >>> process. It seems reasonable to delay any brand new reachable >>> prefixes until after all previously announced ones have been >>> refreshed and the EoRR sent -- if that's the intent here. Changes >>> which occur before the refresh gets to a given entry are pretty >>> naturally swept up by the refresh. Changes which occur after the >>> refresh has gone past, could/should be deferred to after the EoRR ? >>> Does it make a difference if the change is a withdraw ? (Of course >>> MRAI may kick in here. Ah. MRAI and route-refresh, there's a topic >>> !) >>>=20 >>> I think the essence of the rule is that the EoRR should be sent once >>> all prefixes previously advertised to the peer as reachable have been >>> refreshed, ie announced or withdrawn (at least) once. Or, perhaps >>> more strictly, not *before* those prefixes have *all* been announced >>> once -- given that the EoRR will promptly bang un-advertised stuff on >>> the head. Even more strictly perhaps: not send EoRR *before* any >>> withdraws implied by it are required or desirable. >>>=20 >>> Depending on the implementation, a given sender may or may not be >>> able to determine the minimum set of updates required before sending >>>EoRR. >>>=20 >>> If the refresh operation takes a long time, there may be good >>> routeing reasons to arrange for some route changes to be sent to the >>> peer "early" -- that is to send announcements which do not contribute >>> to the refresh, but which are important enough to warrant delaying >>> the end of the refresh. That could be a matter for recommendation(s) >>> in the standard. >>>=20 >>> NB: given that the timing of the EoRR is tied to the state of the >>> Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. At >>> the beginning of the initial update, the Restarting and Receiving >>> speakers have: >>>=20 >>> Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out >>>=20 >>> Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In >>>=20 >>> Now suppose (bonkers or otherwise) the receiving speaker sends an RRQ >>> part way through the initial update. The restarting speaker responds >>> with BoRR, everything in its Adj-RIB-Out, and EoRR -- per >>> specification. The receiving speaker sees the EoRR, and flushes >>> stale. Unfortunately, if the restarting speaker has not yet fully >>> populated its Adj-RIB-Out, then many further routes will be sent >>> before the EoR falls due -- but the receiving speaker has already >>> flushed their tiny posteriors :-( >>>=20 >>> I am coming to the view that route-refresh during a Graceful Restart >>> initial update is a horse of a different colour altogether. >>>=20 >>> [So the assumption that EoRR and EoR are triggered by the same thing >>> was completely wrong, and I apologise for it.] >>>=20 >>> Chris >>>=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 > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From jakob.heitz@ericsson.com Tue Jan 28 12:23:13 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E62651A0440; Tue, 28 Jan 2014 12:23:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1iPK-AMkV_YT; Tue, 28 Jan 2014 12:23:11 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 74D3E1A039E; Tue, 28 Jan 2014 12:23:11 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-48-52e811a9cf6e Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 3E.F1.12743.9A118E25; Tue, 28 Jan 2014 21:23:05 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0387.000; Tue, 28 Jan 2014 15:23:08 -0500 From: Jakob Heitz To: "Keyur Patel (keyupate)" , Thomas Mangin , "idr-bounces@ietf.org" Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPF5KdKHMolEg8TF26AxOKep0T6JqRMOhAgAGfMAD//7gu+4AAX1gA//+1BTCAAHhgAP//sQGgAA5+ToAABygAoAAmsOcAAAoIr7AAJlf4AP//r6/0gAIo+ACAAuS2AIAAU2KQ//+z84CAAFNj0A== Date: Tue, 28 Jan 2014 20:23:07 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F6E252@eusaamb109.ericsson.se> References: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F6E1AF@eusaamb109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyuXRPiO5KwRdBBts3WlnM2Tid1eLV7WdM Fo1bz7NZTNq2mtWBxWPK742sHv1nNzN5LFnykymAOYrLJiU1J7MstUjfLoEro2vJJ8aCp84V 3689YG1gPGjexcjJISFgInH7+Ad2CFtM4sK99WxdjFwcQgJHGCXezPjPApIQEljOKHFmpSuI zSagI/HtehczSJGIwDRGic7GDUwgCWYBRYmLfzvAbGEBN4m7LZ/BbBEBd4mWH5OgGpYxSmzd 3AA2lUVAVWLzv72MXYwcHLwCvhLL2rMhlhVLLNi4kBHE5hQwkJj26ASYzQh03fdTa6B2iUvc ejKfCeJqAYkle84zQ9iiEi8f/2OFsJUkJi09xwpRryOxYPcnNghbW2LZwtdg9bwCghInZz5h mcAoNgvJ2FlIWmYhaZmFpGUBI8sqRo7S4tSy3HQjg02MwCg6JsGmu4Nxz0vLQ4zSHCxK4rxf 3joHCQmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamDUeSTx4+JDz/P8KYveqLO5qNrWC3vt/qeo 3MngUnvQ6se5SdcXMJnlLGBiW7T2h2DEtYoTTr4eOf6Nq+UnsFzau8H/ycT5sUwshcsWeCuv lPjLe/7jPz2G0yf2fXTscufImxNg8SPx9nPtW21CHwUFPlhsyGi12W2X9qbWaU3ej0zj+sYv ImJKLMUZiYZazEXFiQAe3cp9cAIAAA== Cc: "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 20:23:14 -0000 the order BoRR, EoR, EoRR allows this possible scenario: Suppose 2 routes exist :1.1.1.1/32, 2.2.2.2/32 The order could now be: . start session . send 1.1.1.1/32 . receive route refresh request. . send BoRR . send 2.2.2.2/32 . send EoR . send 1.1.1.1/32 . send EoRR On receipt of EoR, the receiver could delete stales, deleting 1.1.1.1/32. Thanks, Jakob. -----Original Message----- From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com]=20 Sent: Tuesday, January 28, 2014 12:17 PM To: Jakob Heitz; Thomas Mangin; idr-bounces@ietf.org Cc: idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh The order: BoRR, EoR, EoRR lets an implementation do both, merge route ref= resh reply with an initial table announcement or delay the route refresh re= plies. As long as EoR is sent before EoRR there should be no issue right? Regards, Keyur On 1/28/14 12:06 PM, "Jakob Heitz" wrote: >Enke's text allows the order: BoRR, EoR, EoRR. > >Could we change Enke's text from >"it MUST NOT send an EoRR" to >"it MUST NOT send an BoRR" > >Thanks, >Jakob. > >-----Original Message----- >From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Keyur Patel >(keyupate) >Sent: Tuesday, January 28, 2014 11:51 AM >To: Thomas Mangin; idr-bounces@ietf.org >Cc: idr@ietf.org >Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh > >Hi Jacob, Thomas, > >Am ok with implementations delaying the servicing of route refresh=20 >request. Enke's suggested text addresses the concern. > >Best Regards, >Keyur > >On 1/26/14 3:39 PM, "Thomas Mangin" >wrote: > >>Damn, time to practice then :) >> >>Joke apart, I agree with this post. The feature should not be used (=20 >>and ignored ) until the initial route exchange has been completed. >> >>If the session drops, I would expect the router to cancel any RR which=20 >>was ongoing as the AdjRIBOut is going to be retransmitted anyway. >> >>Thomas >> >>Sent from my iPad >> >>> On 25 Jan 2014, at 19:48, Jakob Heitz wrote: >>>=20 >>> RFCs are written for coders "practiced" in the art". >>> If anyone sends an EoRR before the adj-RIB-out is fully populated,=20 >>>then it's a BUG. >>> This does not need to be said. >>>=20 >>> Personally, I believe a route refresh request should not be honored=20 >>>until GR is complete. >>> Also, I don't believe a timer for the receipt of EoRR is necessary,=20 >>>because the EoRR is guaranteed. >>> Guaranteed means "unless the session drops first". >>> -- >>>=20 >>> Jakob Heitz. >>>=20 >>> ________________________________________ >>> From: Chris Hall [chris.hall@highwayman.com] >>> Sent: Saturday, 25 January 2014 11:27 AM >>> To: idr@ietf.org >>> Cc: Jakob Heitz >>> Subject: RE: [Idr] WG LC for >>> draft-ietf-idr-bgp-enhanced-route-refresh >>>=20 >>> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): >>> ... >>>> Silence means don't do it. >>>=20 >>> Hmmm.... as a principle I'm more comfortable with "that which isn't=20 >>> prohibited is permitted".... >>>=20 >>>> You would definitely NOT want BoRR to flush old stales. >>>=20 >>> ....but, given the definite requirement, and given that the current=20 >>> precedent for "marking stale" does flush old stale, then a few words=20 >>> for the avoidance of doubt ? >>>=20 >>>> Restarting the timer might be a good idea. >>>=20 >>> I dunno... a route which remains stale for "a long time" is, of=20 >>> course, a candidate for being withdrawn: so having started a timer=20 >>> the first time things are set stale, I would avoid extending that --=20 >>> at least for Graceful Restart, where the whole withdraw thing has=20 >>> been "on-hold" since the last session failed. For route-refresh I=20 >>> guess there's more of a presumption that stale routes will be=20 >>> refreshed sooner or later, and in the meantime they remain good. So=20 >>> if the route-refresh is (repeatedly) restarted for some reason,=20 >>> perhaps it is more reasonable to extend the flush deadline -- but=20 >>> avoid doing this indefinitely ? >>>=20 >>> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I have=20 >>> built in Quagga prioritise route changes (pending changes and any=20 >>> that occur during the refresh) over refresh updates. This makes it=20 >>> more likely that remaining stale routes are still good. But the=20 >>> other end cannot know that. >>>=20 >>> The paragraph in the draft discussing the "entire Adj-RIB-Out" >>> defines that to be the entries present "at the start of the route =20 >>>refresh operation", and observes that these comprise both reachable =20 >>>and unreachable routes. [An "of" after "comprise" sets teeth on =20 >>>edge, BTW.] I'm really not sure what this paragraph is trying to=20 >>>tell me. >>> The reference to unreachable routes appears to suggest that pending =20 >>>withdraws should be sent as part of the refresh -- so not left to the =20 >>>EoRR to implement at the end. The point at which the EoRR is sent is =20 >>>defined such that it excludes any Adj-RIB-Out entries added after the =20 >>>route-refresh started, but includes any which are changed during the =20 >>>process. It seems reasonable to delay any brand new reachable =20 >>>prefixes until after all previously announced ones have been =20 >>>refreshed and the EoRR sent -- if that's the intent here. Changes =20 >>>which occur before the refresh gets to a given entry are pretty =20 >>>naturally swept up by the refresh. Changes which occur after the =20 >>>refresh has gone past, could/should be deferred to after the EoRR ? >>> Does it make a difference if the change is a withdraw ? (Of course =20 >>>MRAI may kick in here. Ah. MRAI and route-refresh, there's a topic >>> !) >>>=20 >>> I think the essence of the rule is that the EoRR should be sent once=20 >>> all prefixes previously advertised to the peer as reachable have=20 >>> been refreshed, ie announced or withdrawn (at least) once. Or,=20 >>> perhaps more strictly, not *before* those prefixes have *all* been=20 >>> announced once -- given that the EoRR will promptly bang=20 >>> un-advertised stuff on the head. Even more strictly perhaps: not=20 >>> send EoRR *before* any withdraws implied by it are required or desirabl= e. >>>=20 >>> Depending on the implementation, a given sender may or may not be =20 >>>able to determine the minimum set of updates required before sending=20 >>>EoRR. >>>=20 >>> If the refresh operation takes a long time, there may be good=20 >>> routeing reasons to arrange for some route changes to be sent to the=20 >>> peer "early" -- that is to send announcements which do not=20 >>> contribute to the refresh, but which are important enough to warrant=20 >>> delaying the end of the refresh. That could be a matter for=20 >>> recommendation(s) in the standard. >>>=20 >>> NB: given that the timing of the EoRR is tied to the state of the=20 >>> Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. =20 >>> At the beginning of the initial update, the Restarting and Receiving=20 >>> speakers have: >>>=20 >>> Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out >>>=20 >>> Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In >>>=20 >>> Now suppose (bonkers or otherwise) the receiving speaker sends an=20 >>> RRQ part way through the initial update. The restarting speaker=20 >>> responds with BoRR, everything in its Adj-RIB-Out, and EoRR -- per=20 >>> specification. The receiving speaker sees the EoRR, and flushes=20 >>> stale. Unfortunately, if the restarting speaker has not yet fully=20 >>> populated its Adj-RIB-Out, then many further routes will be sent=20 >>> before the EoR falls due -- but the receiving speaker has already=20 >>> flushed their tiny posteriors :-( >>>=20 >>> I am coming to the view that route-refresh during a Graceful Restart=20 >>> initial update is a horse of a different colour altogether. >>>=20 >>> [So the assumption that EoRR and EoR are triggered by the same thing=20 >>> was completely wrong, and I apologise for it.] >>>=20 >>> Chris >>>=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 > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From internet-drafts@ietf.org Tue Jan 28 12:41:05 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21BF31A0469; Tue, 28 Jan 2014 12:41:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9oA4oEsM2-q; Tue, 28 Jan 2014 12:41:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 69E941A0465; Tue, 28 Jan 2014 12:41:03 -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: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140128204103.9806.40005.idtracker@ietfa.amsl.com> Date: Tue, 28 Jan 2014 12:41:03 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-flow-spec-v6-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 20:41:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : Dissemination of Flow Specification Rules for IPv6 Authors : Robert Raszuk Burjiz Pithawala Danny McPherson Andy Karch Filename : draft-ietf-idr-flow-spec-v6-04.txt Pages : 9 Date : 2014-01-28 Abstract: Dissemination of Flow Specification Rules [RFC5575] provides a protocol extension for propagation of traffic flow information for the purpose of rate limiting or filtering. The [RFC5575] specifies those extensions for IPv4 protocol data packets. This specification extends the current [RFC5575] and defines changes to the original document in order to make it also usable and applicable to IPv6 data packets. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-flow-spec-v6/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-flow-spec-v6-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-flow-spec-v6-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From keyupate@cisco.com Tue Jan 28 12:49:20 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 472211A0469; Tue, 28 Jan 2014 12:49:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9ADy_8Qo278; Tue, 28 Jan 2014 12:49:16 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 67AE91A001E; Tue, 28 Jan 2014 12:49:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8946; q=dns/txt; s=iport; t=1390942154; x=1392151754; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=g1dD9FtVVx7SF9wZ93wTwilflRDLl2YE7q+RKXyr4do=; b=hbKb/vEtARgP0GgauYdFMjUOT+oScAFHiOzylaMk2Pv0CbKvBcQXVTg7 OnFSqSfAQGAIBV3MT5d34PhdJNJ/SLwid8jup85DocutKIiyRcoUaDVhH 5v4XUDIV9bZ/Vm8v6WxBBA8aHkdI+t15dcWz9ueeOpfDCriYS6WxLfSxl 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAP0W6FKtJV2a/2dsb2JhbABagww4VrxvgRMWdIIlAQEBBAEBATc0CwwGAQgRBAEBAR4JLgsUCQgCBAENBYgFDakToG0TBI5/BwaEMgEDlECDaJIfgy2BaAc7 X-IronPort-AV: E=Sophos;i="4.95,738,1384300800"; d="scan'208";a="16202571" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-2.cisco.com with ESMTP; 28 Jan 2014 20:49:13 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0SKnD4u008535 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Jan 2014 20:49:13 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.228]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Tue, 28 Jan 2014 14:49:13 -0600 From: "Keyur Patel (keyupate)" To: Jakob Heitz , Thomas Mangin , "idr-bounces@ietf.org" Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPHGpmkeX0Ff7T2kONFJ6OHVSLvw== Date: Tue, 28 Jan 2014 20:49:12 +0000 Message-ID: In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F6E252@eusaamb109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [128.107.163.31] Content-Type: text/plain; charset="us-ascii" Content-ID: <6E8B9098F6AA084BB614AC5AAC4B0AC9@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 20:49:20 -0000 On 1/28/14 12:23 PM, "Jakob Heitz" wrote: >the order BoRR, EoR, EoRR allows this possible scenario: > >Suppose 2 routes exist :1.1.1.1/32, 2.2.2.2/32 >The order could now be: >. start session >. send 1.1.1.1/32 >. receive route refresh request. >. send BoRR >. send 2.2.2.2/32 >. send EoR >. send 1.1.1.1/32 >. send EoRR > >On receipt of EoR, the receiver could delete stales, deleting 1.1.1.1/32. Not if you use different flags/bits to mark them stale? Implementations could choose to always postpone the route refresh reply and get the same behavior? Regards, Keyur > >Thanks, >Jakob. > >-----Original Message----- >From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] >Sent: Tuesday, January 28, 2014 12:17 PM >To: Jakob Heitz; Thomas Mangin; idr-bounces@ietf.org >Cc: idr@ietf.org >Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh > >The order: BoRR, EoR, EoRR lets an implementation do both, merge route >refresh reply with an initial table announcement or delay the route >refresh replies. As long as EoR is sent before EoRR there should be no >issue right? > >Regards, >Keyur >On 1/28/14 12:06 PM, "Jakob Heitz" wrote: > >>Enke's text allows the order: BoRR, EoR, EoRR. >> >>Could we change Enke's text from >>"it MUST NOT send an EoRR" to >>"it MUST NOT send an BoRR" >> >>Thanks, >>Jakob. >> >>-----Original Message----- >>From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Keyur Patel >>(keyupate) >>Sent: Tuesday, January 28, 2014 11:51 AM >>To: Thomas Mangin; idr-bounces@ietf.org >>Cc: idr@ietf.org >>Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh >> >>Hi Jacob, Thomas, >> >>Am ok with implementations delaying the servicing of route refresh >>request. Enke's suggested text addresses the concern. >> >>Best Regards, >>Keyur >> >>On 1/26/14 3:39 PM, "Thomas Mangin" >>wrote: >> >>>Damn, time to practice then :) >>> >>>Joke apart, I agree with this post. The feature should not be used ( >>>and ignored ) until the initial route exchange has been completed. >>> >>>If the session drops, I would expect the router to cancel any RR which >>>was ongoing as the AdjRIBOut is going to be retransmitted anyway. >>> >>>Thomas >>> >>>Sent from my iPad >>> >>>> On 25 Jan 2014, at 19:48, Jakob Heitz >>>>wrote: >>>>=20 >>>> RFCs are written for coders "practiced" in the art". >>>> If anyone sends an EoRR before the adj-RIB-out is fully populated, >>>>then it's a BUG. >>>> This does not need to be said. >>>>=20 >>>> Personally, I believe a route refresh request should not be honored >>>>until GR is complete. >>>> Also, I don't believe a timer for the receipt of EoRR is necessary, >>>>because the EoRR is guaranteed. >>>> Guaranteed means "unless the session drops first". >>>> -- >>>>=20 >>>> Jakob Heitz. >>>>=20 >>>> ________________________________________ >>>> From: Chris Hall [chris.hall@highwayman.com] >>>> Sent: Saturday, 25 January 2014 11:27 AM >>>> To: idr@ietf.org >>>> Cc: Jakob Heitz >>>> Subject: RE: [Idr] WG LC for >>>> draft-ietf-idr-bgp-enhanced-route-refresh >>>>=20 >>>> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): >>>> ... >>>>> Silence means don't do it. >>>>=20 >>>> Hmmm.... as a principle I'm more comfortable with "that which isn't >>>> prohibited is permitted".... >>>>=20 >>>>> You would definitely NOT want BoRR to flush old stales. >>>>=20 >>>> ....but, given the definite requirement, and given that the current >>>> precedent for "marking stale" does flush old stale, then a few words >>>> for the avoidance of doubt ? >>>>=20 >>>>> Restarting the timer might be a good idea. >>>>=20 >>>> I dunno... a route which remains stale for "a long time" is, of >>>> course, a candidate for being withdrawn: so having started a timer >>>> the first time things are set stale, I would avoid extending that -- >>>> at least for Graceful Restart, where the whole withdraw thing has >>>> been "on-hold" since the last session failed. For route-refresh I >>>> guess there's more of a presumption that stale routes will be >>>> refreshed sooner or later, and in the meantime they remain good. So >>>> if the route-refresh is (repeatedly) restarted for some reason, >>>> perhaps it is more reasonable to extend the flush deadline -- but >>>> avoid doing this indefinitely ? >>>>=20 >>>> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I have >>>> built in Quagga prioritise route changes (pending changes and any >>>> that occur during the refresh) over refresh updates. This makes it >>>> more likely that remaining stale routes are still good. But the >>>> other end cannot know that. >>>>=20 >>>> The paragraph in the draft discussing the "entire Adj-RIB-Out" >>>> defines that to be the entries present "at the start of the route >>>>refresh operation", and observes that these comprise both reachable >>>>and unreachable routes. [An "of" after "comprise" sets teeth on >>>>edge, BTW.] I'm really not sure what this paragraph is trying to >>>>tell me. >>>> The reference to unreachable routes appears to suggest that pending >>>>withdraws should be sent as part of the refresh -- so not left to the >>>>EoRR to implement at the end. The point at which the EoRR is sent is >>>>defined such that it excludes any Adj-RIB-Out entries added after the >>>>route-refresh started, but includes any which are changed during the >>>>process. It seems reasonable to delay any brand new reachable >>>>prefixes until after all previously announced ones have been >>>>refreshed and the EoRR sent -- if that's the intent here. Changes >>>>which occur before the refresh gets to a given entry are pretty >>>>naturally swept up by the refresh. Changes which occur after the >>>>refresh has gone past, could/should be deferred to after the EoRR ? >>>> Does it make a difference if the change is a withdraw ? (Of course >>>>MRAI may kick in here. Ah. MRAI and route-refresh, there's a topic >>>> !) >>>>=20 >>>> I think the essence of the rule is that the EoRR should be sent once >>>> all prefixes previously advertised to the peer as reachable have >>>> been refreshed, ie announced or withdrawn (at least) once. Or, >>>> perhaps more strictly, not *before* those prefixes have *all* been >>>> announced once -- given that the EoRR will promptly bang >>>> un-advertised stuff on the head. Even more strictly perhaps: not >>>> send EoRR *before* any withdraws implied by it are required or >>>>desirable. >>>>=20 >>>> Depending on the implementation, a given sender may or may not be >>>>able to determine the minimum set of updates required before sending >>>>EoRR. >>>>=20 >>>> If the refresh operation takes a long time, there may be good >>>> routeing reasons to arrange for some route changes to be sent to the >>>> peer "early" -- that is to send announcements which do not >>>> contribute to the refresh, but which are important enough to warrant >>>> delaying the end of the refresh. That could be a matter for >>>> recommendation(s) in the standard. >>>>=20 >>>> NB: given that the timing of the EoRR is tied to the state of the >>>> Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. >>>> At the beginning of the initial update, the Restarting and Receiving >>>> speakers have: >>>>=20 >>>> Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out >>>>=20 >>>> Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In >>>>=20 >>>> Now suppose (bonkers or otherwise) the receiving speaker sends an >>>> RRQ part way through the initial update. The restarting speaker >>>> responds with BoRR, everything in its Adj-RIB-Out, and EoRR -- per >>>> specification. The receiving speaker sees the EoRR, and flushes >>>> stale. Unfortunately, if the restarting speaker has not yet fully >>>> populated its Adj-RIB-Out, then many further routes will be sent >>>> before the EoR falls due -- but the receiving speaker has already >>>> flushed their tiny posteriors :-( >>>>=20 >>>> I am coming to the view that route-refresh during a Graceful Restart >>>> initial update is a horse of a different colour altogether. >>>>=20 >>>> [So the assumption that EoRR and EoR are triggered by the same thing >>>> was completely wrong, and I apologise for it.] >>>>=20 >>>> Chris >>>>=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 >> >>_______________________________________________ >>Idr mailing list >>Idr@ietf.org >>https://www.ietf.org/mailman/listinfo/idr > From jakob.heitz@ericsson.com Tue Jan 28 12:56:37 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C431A034E; Tue, 28 Jan 2014 12:56:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1esJcXwKfrO; Tue, 28 Jan 2014 12:56:34 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1121A026C; Tue, 28 Jan 2014 12:56:34 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-0a-52e81980b0a5 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id B7.75.11484.08918E25; Tue, 28 Jan 2014 21:56:32 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0387.000; Tue, 28 Jan 2014 15:56:31 -0500 From: Jakob Heitz To: "Keyur Patel (keyupate)" , Thomas Mangin , "idr-bounces@ietf.org" Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPF5KdKHMolEg8TF26AxOKep0T6JqRMOhAgAGfMAD//7gu+4AAX1gA//+1BTCAAHhgAP//sQGgAA5+ToAABygAoAAmsOcAAAoIr7AAJlf4AP//r6/0gAIo+ACAAuS2AIAAU2KQ//+z84CAAFNj0P//taAAgABTAKA= Date: Tue, 28 Jan 2014 20:56:29 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F6E332@eusaamb109.ericsson.se> References: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F6E252@eusaamb109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyuXRPrG6D5Isgg3trxC3mbJzOavHq9jMm i8at59ksJm1bzerA4jHl90ZWj/6zm5k8liz5yRTAHMVlk5Kak1mWWqRvl8CVceZiA2vBKa+K 1f8Pszcw7rHtYuTkkBAwkbi8+D8LhC0mceHeerYuRi4OIYEjjBI7j/xigXCWM0pMWvIJrIpN QEfi2/UuZpCEiMA0RonOxg1MIAlmAUWJi387wGxhATeJuy2fwWwRAXeJlh+ToBo2MUpcuLqc GSTBIqAqMe3pW7CpvAK+ErPetTGC2EICxRJHfs5jB7E5BQwkOg4uBrMZge77fmoN1DJxiVtP 5jNB3C0gsWTPeWYIW1Ti5eN/rBC2ksSkpedYIep1JBbs/sQGYWtLLFv4mhlir6DEyZlPWCYw is1CMnYWkpZZSFpmIWlZwMiyipGjtDi1LDfdyHATIzCSjkmwOe5gXPDJ8hCjNAeLkjjvl7fO QUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYBZf+yvyfcHPCUabo993L4pbMaQ2Nar9/vTCo qo9jdZ5ajcyHTTLCShyS79uv/rW4cYP9ttm+m/Oua4f5/iz/cdImtTi76umTBAb3gs8vd0R3 HcwJn1MePd/3m+WzLSnh+9awFllZ3N+youBB1ZrP+S/s10nPVDTScJjwppjJe+7tH7UvOK1k lFiKMxINtZiLihMBRUfl4nICAAA= Cc: "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 20:56:38 -0000 Could we please simplify this a bit, not to force implementations to use di= fferent stale bits? Thanks, Jakob. -----Original Message----- From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com]=20 Sent: Tuesday, January 28, 2014 12:49 PM To: Jakob Heitz; Thomas Mangin; idr-bounces@ietf.org Cc: idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh On 1/28/14 12:23 PM, "Jakob Heitz" wrote: >the order BoRR, EoR, EoRR allows this possible scenario: > >Suppose 2 routes exist :1.1.1.1/32, 2.2.2.2/32 The order could now be: >. start session >. send 1.1.1.1/32 >. receive route refresh request. >. send BoRR >. send 2.2.2.2/32 >. send EoR >. send 1.1.1.1/32 >. send EoRR > >On receipt of EoR, the receiver could delete stales, deleting 1.1.1.1/32. Not if you use different flags/bits to mark them stale? Implementations could choose to always postpone the route refresh reply and= get the same behavior? Regards, Keyur > >Thanks, >Jakob. > >-----Original Message----- >From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] >Sent: Tuesday, January 28, 2014 12:17 PM >To: Jakob Heitz; Thomas Mangin; idr-bounces@ietf.org >Cc: idr@ietf.org >Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh > >The order: BoRR, EoR, EoRR lets an implementation do both, merge route=20 >refresh reply with an initial table announcement or delay the route=20 >refresh replies. As long as EoR is sent before EoRR there should be no=20 >issue right? > >Regards, >Keyur >On 1/28/14 12:06 PM, "Jakob Heitz" wrote: > >>Enke's text allows the order: BoRR, EoR, EoRR. >> >>Could we change Enke's text from >>"it MUST NOT send an EoRR" to >>"it MUST NOT send an BoRR" >> >>Thanks, >>Jakob. >> >>-----Original Message----- >>From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Keyur Patel >>(keyupate) >>Sent: Tuesday, January 28, 2014 11:51 AM >>To: Thomas Mangin; idr-bounces@ietf.org >>Cc: idr@ietf.org >>Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh >> >>Hi Jacob, Thomas, >> >>Am ok with implementations delaying the servicing of route refresh=20 >>request. Enke's suggested text addresses the concern. >> >>Best Regards, >>Keyur >> >>On 1/26/14 3:39 PM, "Thomas Mangin" >>wrote: >> >>>Damn, time to practice then :) >>> >>>Joke apart, I agree with this post. The feature should not be used (=20 >>>and ignored ) until the initial route exchange has been completed. >>> >>>If the session drops, I would expect the router to cancel any RR=20 >>>which was ongoing as the AdjRIBOut is going to be retransmitted anyway. >>> >>>Thomas >>> >>>Sent from my iPad >>> >>>> On 25 Jan 2014, at 19:48, Jakob Heitz >>>>wrote: >>>>=20 >>>> RFCs are written for coders "practiced" in the art". >>>> If anyone sends an EoRR before the adj-RIB-out is fully populated,=20 >>>>then it's a BUG. >>>> This does not need to be said. >>>>=20 >>>> Personally, I believe a route refresh request should not be honored=20 >>>>until GR is complete. >>>> Also, I don't believe a timer for the receipt of EoRR is necessary,=20 >>>>because the EoRR is guaranteed. >>>> Guaranteed means "unless the session drops first". >>>> -- >>>>=20 >>>> Jakob Heitz. >>>>=20 >>>> ________________________________________ >>>> From: Chris Hall [chris.hall@highwayman.com] >>>> Sent: Saturday, 25 January 2014 11:27 AM >>>> To: idr@ietf.org >>>> Cc: Jakob Heitz >>>> Subject: RE: [Idr] WG LC for >>>> draft-ietf-idr-bgp-enhanced-route-refresh >>>>=20 >>>> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): >>>> ... >>>>> Silence means don't do it. >>>>=20 >>>> Hmmm.... as a principle I'm more comfortable with "that which isn't=20 >>>> prohibited is permitted".... >>>>=20 >>>>> You would definitely NOT want BoRR to flush old stales. >>>>=20 >>>> ....but, given the definite requirement, and given that the current=20 >>>> precedent for "marking stale" does flush old stale, then a few=20 >>>> words for the avoidance of doubt ? >>>>=20 >>>>> Restarting the timer might be a good idea. >>>>=20 >>>> I dunno... a route which remains stale for "a long time" is, of=20 >>>> course, a candidate for being withdrawn: so having started a timer=20 >>>> the first time things are set stale, I would avoid extending that=20 >>>> -- at least for Graceful Restart, where the whole withdraw thing=20 >>>> has been "on-hold" since the last session failed. For=20 >>>> route-refresh I guess there's more of a presumption that stale=20 >>>> routes will be refreshed sooner or later, and in the meantime they=20 >>>> remain good. So if the route-refresh is (repeatedly) restarted for=20 >>>> some reason, perhaps it is more reasonable to extend the flush=20 >>>> deadline -- but avoid doing this indefinitely ? >>>>=20 >>>> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I=20 >>>> have built in Quagga prioritise route changes (pending changes and=20 >>>> any that occur during the refresh) over refresh updates. This=20 >>>> makes it more likely that remaining stale routes are still good. =20 >>>> But the other end cannot know that. >>>>=20 >>>> The paragraph in the draft discussing the "entire Adj-RIB-Out" >>>> defines that to be the entries present "at the start of the route=20 >>>>refresh operation", and observes that these comprise both reachable=20 >>>>and unreachable routes. [An "of" after "comprise" sets teeth on=20 >>>>edge, BTW.] I'm really not sure what this paragraph is trying to=20 >>>>tell me. >>>> The reference to unreachable routes appears to suggest that pending=20 >>>>withdraws should be sent as part of the refresh -- so not left to=20 >>>>the EoRR to implement at the end. The point at which the EoRR is=20 >>>>sent is defined such that it excludes any Adj-RIB-Out entries added=20 >>>>after the route-refresh started, but includes any which are changed=20 >>>>during the process. It seems reasonable to delay any brand new=20 >>>>reachable prefixes until after all previously announced ones have=20 >>>>been refreshed and the EoRR sent -- if that's the intent here. =20 >>>>Changes which occur before the refresh gets to a given entry are=20 >>>>pretty naturally swept up by the refresh. Changes which occur after=20 >>>>the refresh has gone past, could/should be deferred to after the EoRR ? >>>> Does it make a difference if the change is a withdraw ? (Of course=20 >>>>MRAI may kick in here. Ah. MRAI and route-refresh, there's a topic >>>> !) >>>>=20 >>>> I think the essence of the rule is that the EoRR should be sent=20 >>>>once all prefixes previously advertised to the peer as reachable=20 >>>>have been refreshed, ie announced or withdrawn (at least) once. =20 >>>>Or, perhaps more strictly, not *before* those prefixes have *all*=20 >>>>been announced once -- given that the EoRR will promptly bang =20 >>>>un-advertised stuff on the head. Even more strictly perhaps: not =20 >>>>send EoRR *before* any withdraws implied by it are required or=20 >>>>desirable. >>>>=20 >>>> Depending on the implementation, a given sender may or may not be=20 >>>>able to determine the minimum set of updates required before sending=20 >>>>EoRR. >>>>=20 >>>> If the refresh operation takes a long time, there may be good=20 >>>> routeing reasons to arrange for some route changes to be sent to=20 >>>> the peer "early" -- that is to send announcements which do not=20 >>>> contribute to the refresh, but which are important enough to=20 >>>> warrant delaying the end of the refresh. That could be a matter=20 >>>> for >>>> recommendation(s) in the standard. >>>>=20 >>>> NB: given that the timing of the EoRR is tied to the state of the=20 >>>> Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. >>>> At the beginning of the initial update, the Restarting and=20 >>>> Receiving speakers have: >>>>=20 >>>> Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out >>>>=20 >>>> Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In >>>>=20 >>>> Now suppose (bonkers or otherwise) the receiving speaker sends an=20 >>>> RRQ part way through the initial update. The restarting speaker=20 >>>> responds with BoRR, everything in its Adj-RIB-Out, and EoRR -- per=20 >>>> specification. The receiving speaker sees the EoRR, and flushes=20 >>>> stale. Unfortunately, if the restarting speaker has not yet fully=20 >>>> populated its Adj-RIB-Out, then many further routes will be sent=20 >>>> before the EoR falls due -- but the receiving speaker has already=20 >>>> flushed their tiny posteriors :-( >>>>=20 >>>> I am coming to the view that route-refresh during a Graceful=20 >>>> Restart initial update is a horse of a different colour altogether. >>>>=20 >>>> [So the assumption that EoRR and EoR are triggered by the same=20 >>>> thing was completely wrong, and I apologise for it.] >>>>=20 >>>> Chris >>>>=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 >> >>_______________________________________________ >>Idr mailing list >>Idr@ietf.org >>https://www.ietf.org/mailman/listinfo/idr > From keyupate@cisco.com Tue Jan 28 13:08:09 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9C71A03C4; Tue, 28 Jan 2014 13:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F26FDY5zDbKC; Tue, 28 Jan 2014 13:08:05 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7041A03B7; Tue, 28 Jan 2014 13:08:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9912; q=dns/txt; s=iport; t=1390943283; x=1392152883; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=nSXOo6Qquwb7hi+300k5SRz1dVMdmB9lT1+NjoJAEHA=; b=e9/9WOWvDrLwr7laHuSdrP8rCldAcmDKoXy4qpuuQxd4j+u6KGOm8uX+ qlUEnC6AHTiF2/6tokA3gNHBklWhPphLCVKsD3ceHLuZqLHgcBdAevCVw 7rdAphWbrwQYC39MTW1+6GpU6mE2H3wIsx52kTACamjvVOl0JGy1m6vMH U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FABsb6FKtJV2c/2dsb2JhbABagww4Vrx1gRMWdIIlAQEBBAEBATc0CwwGAQgRBAEBAR4JLgsUCQgCBAENBYgFDakNoGwTBI5/BwaEMgEDlECDaJIfgy2CKg X-IronPort-AV: E=Sophos;i="4.95,738,1384300800"; d="scan'208";a="300117648" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 28 Jan 2014 21:08:02 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s0SL82dB025209 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Jan 2014 21:08:02 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.228]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Tue, 28 Jan 2014 15:08:01 -0600 From: "Keyur Patel (keyupate)" To: Jakob Heitz , Thomas Mangin , "idr-bounces@ietf.org" Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPHG0GkeX0Ff7T2kONFJ6OHVSLvw== Date: Tue, 28 Jan 2014 21:08:01 +0000 Message-ID: In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F6E332@eusaamb109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [128.107.163.31] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 21:08:09 -0000 Sure! I am saying you can simplify the implementation by simply delaying the servicing of the route refresh reply till the generation of an EOR. Question is do we allow the text to be flexible enough to cover the other case. :) Regards, Keyur On 1/28/14 12:56 PM, "Jakob Heitz" wrote: >Could we please simplify this a bit, not to force implementations to use >different stale bits? > >Thanks, >Jakob. > >-----Original Message----- >From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] >Sent: Tuesday, January 28, 2014 12:49 PM >To: Jakob Heitz; Thomas Mangin; idr-bounces@ietf.org >Cc: idr@ietf.org >Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh > > > >On 1/28/14 12:23 PM, "Jakob Heitz" wrote: > >>the order BoRR, EoR, EoRR allows this possible scenario: >> >>Suppose 2 routes exist :1.1.1.1/32, 2.2.2.2/32 The order could now be: >>. start session >>. send 1.1.1.1/32 >>. receive route refresh request. >>. send BoRR >>. send 2.2.2.2/32 >>. send EoR >>. send 1.1.1.1/32 >>. send EoRR >> >>On receipt of EoR, the receiver could delete stales, deleting 1.1.1.1/32. > >Not if you use different flags/bits to mark them stale? > >Implementations could choose to always postpone the route refresh reply >and get the same behavior? > >Regards, >Keyur > >> >>Thanks, >>Jakob. >> >>-----Original Message----- >>From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] >>Sent: Tuesday, January 28, 2014 12:17 PM >>To: Jakob Heitz; Thomas Mangin; idr-bounces@ietf.org >>Cc: idr@ietf.org >>Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh >> >>The order: BoRR, EoR, EoRR lets an implementation do both, merge route >>refresh reply with an initial table announcement or delay the route >>refresh replies. As long as EoR is sent before EoRR there should be no >>issue right? >> >>Regards, >>Keyur >>On 1/28/14 12:06 PM, "Jakob Heitz" wrote: >> >>>Enke's text allows the order: BoRR, EoR, EoRR. >>> >>>Could we change Enke's text from >>>"it MUST NOT send an EoRR" to >>>"it MUST NOT send an BoRR" >>> >>>Thanks, >>>Jakob. >>> >>>-----Original Message----- >>>From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Keyur Patel >>>(keyupate) >>>Sent: Tuesday, January 28, 2014 11:51 AM >>>To: Thomas Mangin; idr-bounces@ietf.org >>>Cc: idr@ietf.org >>>Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh >>> >>>Hi Jacob, Thomas, >>> >>>Am ok with implementations delaying the servicing of route refresh >>>request. Enke's suggested text addresses the concern. >>> >>>Best Regards, >>>Keyur >>> >>>On 1/26/14 3:39 PM, "Thomas Mangin" >>>wrote: >>> >>>>Damn, time to practice then :) >>>> >>>>Joke apart, I agree with this post. The feature should not be used ( >>>>and ignored ) until the initial route exchange has been completed. >>>> >>>>If the session drops, I would expect the router to cancel any RR >>>>which was ongoing as the AdjRIBOut is going to be retransmitted anyway. >>>> >>>>Thomas >>>> >>>>Sent from my iPad >>>> >>>>> On 25 Jan 2014, at 19:48, Jakob Heitz >>>>>wrote: >>>>>=20 >>>>> RFCs are written for coders "practiced" in the art". >>>>> If anyone sends an EoRR before the adj-RIB-out is fully populated, >>>>>then it's a BUG. >>>>> This does not need to be said. >>>>>=20 >>>>> Personally, I believe a route refresh request should not be honored >>>>>until GR is complete. >>>>> Also, I don't believe a timer for the receipt of EoRR is necessary, >>>>>because the EoRR is guaranteed. >>>>> Guaranteed means "unless the session drops first". >>>>> -- >>>>>=20 >>>>> Jakob Heitz. >>>>>=20 >>>>> ________________________________________ >>>>> From: Chris Hall [chris.hall@highwayman.com] >>>>> Sent: Saturday, 25 January 2014 11:27 AM >>>>> To: idr@ietf.org >>>>> Cc: Jakob Heitz >>>>> Subject: RE: [Idr] WG LC for >>>>> draft-ietf-idr-bgp-enhanced-route-refresh >>>>>=20 >>>>> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): >>>>> ... >>>>>> Silence means don't do it. >>>>>=20 >>>>> Hmmm.... as a principle I'm more comfortable with "that which isn't >>>>> prohibited is permitted".... >>>>>=20 >>>>>> You would definitely NOT want BoRR to flush old stales. >>>>>=20 >>>>> ....but, given the definite requirement, and given that the current >>>>> precedent for "marking stale" does flush old stale, then a few >>>>> words for the avoidance of doubt ? >>>>>=20 >>>>>> Restarting the timer might be a good idea. >>>>>=20 >>>>> I dunno... a route which remains stale for "a long time" is, of >>>>> course, a candidate for being withdrawn: so having started a timer >>>>> the first time things are set stale, I would avoid extending that >>>>> -- at least for Graceful Restart, where the whole withdraw thing >>>>> has been "on-hold" since the last session failed. For >>>>> route-refresh I guess there's more of a presumption that stale >>>>> routes will be refreshed sooner or later, and in the meantime they >>>>> remain good. So if the route-refresh is (repeatedly) restarted for >>>>> some reason, perhaps it is more reasonable to extend the flush >>>>> deadline -- but avoid doing this indefinitely ? >>>>>=20 >>>>> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I >>>>> have built in Quagga prioritise route changes (pending changes and >>>>> any that occur during the refresh) over refresh updates. This >>>>> makes it more likely that remaining stale routes are still good. >>>>> But the other end cannot know that. >>>>>=20 >>>>> The paragraph in the draft discussing the "entire Adj-RIB-Out" >>>>> defines that to be the entries present "at the start of the route >>>>>refresh operation", and observes that these comprise both reachable >>>>>and unreachable routes. [An "of" after "comprise" sets teeth on >>>>>edge, BTW.] I'm really not sure what this paragraph is trying to >>>>>tell me. >>>>> The reference to unreachable routes appears to suggest that pending >>>>>withdraws should be sent as part of the refresh -- so not left to >>>>>the EoRR to implement at the end. The point at which the EoRR is >>>>>sent is defined such that it excludes any Adj-RIB-Out entries added >>>>>after the route-refresh started, but includes any which are changed >>>>>during the process. It seems reasonable to delay any brand new >>>>>reachable prefixes until after all previously announced ones have >>>>>been refreshed and the EoRR sent -- if that's the intent here. >>>>>Changes which occur before the refresh gets to a given entry are >>>>>pretty naturally swept up by the refresh. Changes which occur after >>>>>the refresh has gone past, could/should be deferred to after the EoRR >>>>>? >>>>> Does it make a difference if the change is a withdraw ? (Of course >>>>>MRAI may kick in here. Ah. MRAI and route-refresh, there's a topic >>>>> !) >>>>>=20 >>>>> I think the essence of the rule is that the EoRR should be sent >>>>>once all prefixes previously advertised to the peer as reachable >>>>>have been refreshed, ie announced or withdrawn (at least) once. >>>>>Or, perhaps more strictly, not *before* those prefixes have *all* >>>>>been announced once -- given that the EoRR will promptly bang >>>>>un-advertised stuff on the head. Even more strictly perhaps: not >>>>>send EoRR *before* any withdraws implied by it are required or >>>>>desirable. >>>>>=20 >>>>> Depending on the implementation, a given sender may or may not be >>>>>able to determine the minimum set of updates required before sending >>>>>EoRR. >>>>>=20 >>>>> If the refresh operation takes a long time, there may be good >>>>> routeing reasons to arrange for some route changes to be sent to >>>>> the peer "early" -- that is to send announcements which do not >>>>> contribute to the refresh, but which are important enough to >>>>> warrant delaying the end of the refresh. That could be a matter >>>>> for >>>>> recommendation(s) in the standard. >>>>>=20 >>>>> NB: given that the timing of the EoRR is tied to the state of the >>>>> Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. >>>>> At the beginning of the initial update, the Restarting and >>>>> Receiving speakers have: >>>>>=20 >>>>> Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out >>>>>=20 >>>>> Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In >>>>>=20 >>>>> Now suppose (bonkers or otherwise) the receiving speaker sends an >>>>> RRQ part way through the initial update. The restarting speaker >>>>> responds with BoRR, everything in its Adj-RIB-Out, and EoRR -- per >>>>> specification. The receiving speaker sees the EoRR, and flushes >>>>> stale. Unfortunately, if the restarting speaker has not yet fully >>>>> populated its Adj-RIB-Out, then many further routes will be sent >>>>> before the EoR falls due -- but the receiving speaker has already >>>>> flushed their tiny posteriors :-( >>>>>=20 >>>>> I am coming to the view that route-refresh during a Graceful >>>>> Restart initial update is a horse of a different colour altogether. >>>>>=20 >>>>> [So the assumption that EoRR and EoR are triggered by the same >>>>> thing was completely wrong, and I apologise for it.] >>>>>=20 >>>>> Chris >>>>>=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 >>> >>>_______________________________________________ >>>Idr mailing list >>>Idr@ietf.org >>>https://www.ietf.org/mailman/listinfo/idr >> > From keyupate@cisco.com Tue Jan 28 13:43:26 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B1E1A0424; Tue, 28 Jan 2014 13:43:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cy7wMa-DwSes; Tue, 28 Jan 2014 13:43:22 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id F37151A0418; Tue, 28 Jan 2014 13:43:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10844; q=dns/txt; s=iport; t=1390945399; x=1392154999; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=BKA7O01CYsLyAWS2uqsknbb1fHDeFQ3lyrdNa4mAlNs=; b=i3XIZtwvSLV/Yx5A1uVelwD+sBFVx8lyNnJIomLgftuqrqfPjKoEnEwl K3GKAqTGFfBMUdOUa3pUhfAElrQ/qDfLLLVjiWvUWyjg3Xz/X/5gfLXsr RlhK5tc2B+C4lnImNYHRVuqalGmKPCaPo8vDqOirewmxraLzDzcKjUQgt 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkwHADUk6FKtJV2b/2dsb2JhbABagww4Swu8eIETFnSCJQEBAQQBAQE3NAsMBgEIEQQBAQEeCS4LFAkIAgQBDQWIBQ2pCaBTEwSOfwcGhDIBA5RAg2iSH4Mtgio X-IronPort-AV: E=Sophos;i="4.95,738,1384300800"; d="scan'208";a="16214061" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP; 28 Jan 2014 21:43:03 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0SLh3ND007665 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Jan 2014 21:43:03 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.228]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Tue, 28 Jan 2014 15:43:02 -0600 From: "Keyur Patel (keyupate)" To: "Keyur Patel (keyupate)" , Jakob Heitz , Thomas Mangin , "idr-bounces@ietf.org" Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPHHHrkeX0Ff7T2kONFJ6OHVSLvw== Date: Tue, 28 Jan 2014 21:43:01 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [128.107.163.31] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 21:43:26 -0000 Hi Jakob,=20 How about the following (based on your suggestion): For a BGP speaker that supports the BGP Graceful Restart specified in [RFC4724] , it MUST NOT send a BoRR for an AFI/SAFI to a neighbor before it sends the EOR for the AFI/SAFI to the neighbor. This procedure would help the neighbor avoid the premature cleanup of stale routes. This would help simplify receiver side implementation wrt GR and Enhanced RR. :) Regards, Keyur On 1/28/14 1:08 PM, "Keyur Patel (keyupate)" wrote: >Sure! I am saying you can simplify the implementation by simply delaying >the servicing of the route refresh reply till the generation of an EOR. > >Question is do we allow the text to be flexible enough to cover the other >case. :) > >Regards, >Keyur > >On 1/28/14 12:56 PM, "Jakob Heitz" wrote: > >>Could we please simplify this a bit, not to force implementations to use >>different stale bits? >> >>Thanks, >>Jakob. >> >>-----Original Message----- >>From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] >>Sent: Tuesday, January 28, 2014 12:49 PM >>To: Jakob Heitz; Thomas Mangin; idr-bounces@ietf.org >>Cc: idr@ietf.org >>Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh >> >> >> >>On 1/28/14 12:23 PM, "Jakob Heitz" wrote: >> >>>the order BoRR, EoR, EoRR allows this possible scenario: >>> >>>Suppose 2 routes exist :1.1.1.1/32, 2.2.2.2/32 The order could now be: >>>. start session >>>. send 1.1.1.1/32 >>>. receive route refresh request. >>>. send BoRR >>>. send 2.2.2.2/32 >>>. send EoR >>>. send 1.1.1.1/32 >>>. send EoRR >>> >>>On receipt of EoR, the receiver could delete stales, deleting >>>1.1.1.1/32. >> >>Not if you use different flags/bits to mark them stale? >> >>Implementations could choose to always postpone the route refresh reply >>and get the same behavior? >> >>Regards, >>Keyur >> >>> >>>Thanks, >>>Jakob. >>> >>>-----Original Message----- >>>From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] >>>Sent: Tuesday, January 28, 2014 12:17 PM >>>To: Jakob Heitz; Thomas Mangin; idr-bounces@ietf.org >>>Cc: idr@ietf.org >>>Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh >>> >>>The order: BoRR, EoR, EoRR lets an implementation do both, merge route >>>refresh reply with an initial table announcement or delay the route >>>refresh replies. As long as EoR is sent before EoRR there should be no >>>issue right? >>> >>>Regards, >>>Keyur >>>On 1/28/14 12:06 PM, "Jakob Heitz" wrote: >>> >>>>Enke's text allows the order: BoRR, EoR, EoRR. >>>> >>>>Could we change Enke's text from >>>>"it MUST NOT send an EoRR" to >>>>"it MUST NOT send an BoRR" >>>> >>>>Thanks, >>>>Jakob. >>>> >>>>-----Original Message----- >>>>From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Keyur Patel >>>>(keyupate) >>>>Sent: Tuesday, January 28, 2014 11:51 AM >>>>To: Thomas Mangin; idr-bounces@ietf.org >>>>Cc: idr@ietf.org >>>>Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh >>>> >>>>Hi Jacob, Thomas, >>>> >>>>Am ok with implementations delaying the servicing of route refresh >>>>request. Enke's suggested text addresses the concern. >>>> >>>>Best Regards, >>>>Keyur >>>> >>>>On 1/26/14 3:39 PM, "Thomas Mangin" >>>>wrote: >>>> >>>>>Damn, time to practice then :) >>>>> >>>>>Joke apart, I agree with this post. The feature should not be used ( >>>>>and ignored ) until the initial route exchange has been completed. >>>>> >>>>>If the session drops, I would expect the router to cancel any RR >>>>>which was ongoing as the AdjRIBOut is going to be retransmitted >>>>>anyway. >>>>> >>>>>Thomas >>>>> >>>>>Sent from my iPad >>>>> >>>>>> On 25 Jan 2014, at 19:48, Jakob Heitz >>>>>>wrote: >>>>>>=20 >>>>>> RFCs are written for coders "practiced" in the art". >>>>>> If anyone sends an EoRR before the adj-RIB-out is fully populated, >>>>>>then it's a BUG. >>>>>> This does not need to be said. >>>>>>=20 >>>>>> Personally, I believe a route refresh request should not be honored >>>>>>until GR is complete. >>>>>> Also, I don't believe a timer for the receipt of EoRR is necessary, >>>>>>because the EoRR is guaranteed. >>>>>> Guaranteed means "unless the session drops first". >>>>>> -- >>>>>>=20 >>>>>> Jakob Heitz. >>>>>>=20 >>>>>> ________________________________________ >>>>>> From: Chris Hall [chris.hall@highwayman.com] >>>>>> Sent: Saturday, 25 January 2014 11:27 AM >>>>>> To: idr@ietf.org >>>>>> Cc: Jakob Heitz >>>>>> Subject: RE: [Idr] WG LC for >>>>>> draft-ietf-idr-bgp-enhanced-route-refresh >>>>>>=20 >>>>>> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): >>>>>> ... >>>>>>> Silence means don't do it. >>>>>>=20 >>>>>> Hmmm.... as a principle I'm more comfortable with "that which isn't >>>>>> prohibited is permitted".... >>>>>>=20 >>>>>>> You would definitely NOT want BoRR to flush old stales. >>>>>>=20 >>>>>> ....but, given the definite requirement, and given that the current >>>>>> precedent for "marking stale" does flush old stale, then a few >>>>>> words for the avoidance of doubt ? >>>>>>=20 >>>>>>> Restarting the timer might be a good idea. >>>>>>=20 >>>>>> I dunno... a route which remains stale for "a long time" is, of >>>>>> course, a candidate for being withdrawn: so having started a timer >>>>>> the first time things are set stale, I would avoid extending that >>>>>> -- at least for Graceful Restart, where the whole withdraw thing >>>>>> has been "on-hold" since the last session failed. For >>>>>> route-refresh I guess there's more of a presumption that stale >>>>>> routes will be refreshed sooner or later, and in the meantime they >>>>>> remain good. So if the route-refresh is (repeatedly) restarted for >>>>>> some reason, perhaps it is more reasonable to extend the flush >>>>>> deadline -- but avoid doing this indefinitely ? >>>>>>=20 >>>>>> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I >>>>>> have built in Quagga prioritise route changes (pending changes and >>>>>> any that occur during the refresh) over refresh updates. This >>>>>> makes it more likely that remaining stale routes are still good. >>>>>> But the other end cannot know that. >>>>>>=20 >>>>>> The paragraph in the draft discussing the "entire Adj-RIB-Out" >>>>>> defines that to be the entries present "at the start of the route >>>>>>refresh operation", and observes that these comprise both reachable >>>>>>and unreachable routes. [An "of" after "comprise" sets teeth on >>>>>>edge, BTW.] I'm really not sure what this paragraph is trying to >>>>>>tell me. >>>>>> The reference to unreachable routes appears to suggest that pending >>>>>>withdraws should be sent as part of the refresh -- so not left to >>>>>>the EoRR to implement at the end. The point at which the EoRR is >>>>>>sent is defined such that it excludes any Adj-RIB-Out entries added >>>>>>after the route-refresh started, but includes any which are changed >>>>>>during the process. It seems reasonable to delay any brand new >>>>>>reachable prefixes until after all previously announced ones have >>>>>>been refreshed and the EoRR sent -- if that's the intent here. >>>>>>Changes which occur before the refresh gets to a given entry are >>>>>>pretty naturally swept up by the refresh. Changes which occur after >>>>>>the refresh has gone past, could/should be deferred to after the EoRR >>>>>>? >>>>>> Does it make a difference if the change is a withdraw ? (Of course >>>>>>MRAI may kick in here. Ah. MRAI and route-refresh, there's a topic >>>>>> !) >>>>>>=20 >>>>>> I think the essence of the rule is that the EoRR should be sent >>>>>>once all prefixes previously advertised to the peer as reachable >>>>>>have been refreshed, ie announced or withdrawn (at least) once. >>>>>>Or, perhaps more strictly, not *before* those prefixes have *all* >>>>>>been announced once -- given that the EoRR will promptly bang >>>>>>un-advertised stuff on the head. Even more strictly perhaps: not >>>>>>send EoRR *before* any withdraws implied by it are required or >>>>>>desirable. >>>>>>=20 >>>>>> Depending on the implementation, a given sender may or may not be >>>>>>able to determine the minimum set of updates required before sending >>>>>>EoRR. >>>>>>=20 >>>>>> If the refresh operation takes a long time, there may be good >>>>>> routeing reasons to arrange for some route changes to be sent to >>>>>> the peer "early" -- that is to send announcements which do not >>>>>> contribute to the refresh, but which are important enough to >>>>>> warrant delaying the end of the refresh. That could be a matter >>>>>> for >>>>>> recommendation(s) in the standard. >>>>>>=20 >>>>>> NB: given that the timing of the EoRR is tied to the state of the >>>>>> Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. >>>>>> At the beginning of the initial update, the Restarting and >>>>>> Receiving speakers have: >>>>>>=20 >>>>>> Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out >>>>>>=20 >>>>>> Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In >>>>>>=20 >>>>>> Now suppose (bonkers or otherwise) the receiving speaker sends an >>>>>> RRQ part way through the initial update. The restarting speaker >>>>>> responds with BoRR, everything in its Adj-RIB-Out, and EoRR -- per >>>>>> specification. The receiving speaker sees the EoRR, and flushes >>>>>> stale. Unfortunately, if the restarting speaker has not yet fully >>>>>> populated its Adj-RIB-Out, then many further routes will be sent >>>>>> before the EoR falls due -- but the receiving speaker has already >>>>>> flushed their tiny posteriors :-( >>>>>>=20 >>>>>> I am coming to the view that route-refresh during a Graceful >>>>>> Restart initial update is a horse of a different colour altogether. >>>>>>=20 >>>>>> [So the assumption that EoRR and EoR are triggered by the same >>>>>> thing was completely wrong, and I apologise for it.] >>>>>>=20 >>>>>> Chris >>>>>>=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 >>>> >>>>_______________________________________________ >>>>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 Tue Jan 28 14:53:47 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17F601A029E; Tue, 28 Jan 2014 14:53:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xtgrnoYfBT3; Tue, 28 Jan 2014 14:53:43 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 908A61A026E; Tue, 28 Jan 2014 14:53:43 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-70-52e834f17580 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id CD.89.12743.1F438E25; Tue, 28 Jan 2014 23:53:37 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0387.000; Tue, 28 Jan 2014 17:53:40 -0500 From: Jakob Heitz To: "Keyur Patel (keyupate)" , Thomas Mangin , "idr-bounces@ietf.org" Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPF5KdKHMolEg8TF26AxOKep0T6JqRMOhAgAGfMAD//7gu+4AAX1gA//+1BTCAAHhgAP//sQGgAA5+ToAABygAoAAmsOcAAAoIr7AAJlf4AP//r6/0gAIo+ACAAuS2AIAAU2KQ//+z84CAAFNj0P//taAAgABTAKD//7JCgAABOPmAAAgFSIA= Date: Tue, 28 Jan 2014 22:53:38 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F6E528@eusaamb109.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyuXRPrO5HkxdBBqfnWFjM2Tid1eLV7WdM Fo1bz7NZTNq2mtWBxWPK742sHv1nNzN5LFnykymAOYrLJiU1J7MstUjfLoEr49nV46wFGyMr fsyra2Bc4tXFyMkhIWAiceriRSYIW0ziwr31bF2MXBxCAkcYJV58PscC4SxnlLh+6gwzSBWb gI7Et+tdzCAJEYFpjBKdjRvA2pkFFCUu/u0As4UF3CTutnwGs0UE3CVafkyCajjGKPH83G9W kASLgKrE7f8/wKbyCvhKHJo+mw3EFhIIlfi5ZBNjFyMHB6eAgcSSW2AljEDnfT+1BmqXuMSt J/OhzhaQWLLnPDOELSrx8vE/VghbSWLS0nOsEPU6Egt2f2KDsLUlli18DbVWUOLkzCcsExjF ZiEZOwtJyywkLbOQtCxgZFnFyFFanFqWm25ksIkRGEXHJNh0dzDueWl5iFGag0VJnPfLW+cg IYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYztTlc9uPuvf97XfPGf9wqpCdLy+Qd4vSIqtVj2 vz4bcIClvaLkNmv+KuMu+5KDU4Nvb+zaenf+IwWO7O9nT/1aV5aQfu18yPX2lY4Ku0Wibpz/ /3JlV/yK61FK+gZPbl31OC/J+Ff6c/iGo5fnnH0aVMc8rfbrnM9LD+qbVm1hUCrlqJP/sHem EktxRqKhFnNRcSIAAIPxiHACAAA= Cc: "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 22:53:47 -0000 Sold. Thanks, Jakob. -----Original Message----- From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com]=20 Sent: Tuesday, January 28, 2014 1:43 PM To: Keyur Patel (keyupate); Jakob Heitz; Thomas Mangin; idr-bounces@ietf.or= g Cc: idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Jakob,=20 How about the following (based on your suggestion): For a BGP speaker that supports the BGP Graceful Restart specified in [RFC4= 724] , it MUST NOT send a BoRR for an AFI/SAFI to a neighbor before it send= s the EOR for the AFI/SAFI to the neighbor. This procedure would help the = neighbor avoid the premature cleanup of stale routes. This would help simplify receiver side implementation wrt GR and Enhanced R= R. :) Regards, Keyur On 1/28/14 1:08 PM, "Keyur Patel (keyupate)" wrote: >Sure! I am saying you can simplify the implementation by simply=20 >delaying the servicing of the route refresh reply till the generation of a= n EOR. > >Question is do we allow the text to be flexible enough to cover the=20 >other case. :) > >Regards, >Keyur > >On 1/28/14 12:56 PM, "Jakob Heitz" wrote: > >>Could we please simplify this a bit, not to force implementations to=20 >>use different stale bits? >> >>Thanks, >>Jakob. >> >>-----Original Message----- >>From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] >>Sent: Tuesday, January 28, 2014 12:49 PM >>To: Jakob Heitz; Thomas Mangin; idr-bounces@ietf.org >>Cc: idr@ietf.org >>Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh >> >> >> >>On 1/28/14 12:23 PM, "Jakob Heitz" wrote: >> >>>the order BoRR, EoR, EoRR allows this possible scenario: >>> >>>Suppose 2 routes exist :1.1.1.1/32, 2.2.2.2/32 The order could now be: >>>. start session >>>. send 1.1.1.1/32 >>>. receive route refresh request. >>>. send BoRR >>>. send 2.2.2.2/32 >>>. send EoR >>>. send 1.1.1.1/32 >>>. send EoRR >>> >>>On receipt of EoR, the receiver could delete stales, deleting=20 >>>1.1.1.1/32. >> >>Not if you use different flags/bits to mark them stale? >> >>Implementations could choose to always postpone the route refresh=20 >>reply and get the same behavior? >> >>Regards, >>Keyur >> >>> >>>Thanks, >>>Jakob. >>> >>>-----Original Message----- >>>From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] >>>Sent: Tuesday, January 28, 2014 12:17 PM >>>To: Jakob Heitz; Thomas Mangin; idr-bounces@ietf.org >>>Cc: idr@ietf.org >>>Subject: Re: [Idr] WG LC for=20 >>>draft-ietf-idr-bgp-enhanced-route-refresh >>> >>>The order: BoRR, EoR, EoRR lets an implementation do both, merge=20 >>>route refresh reply with an initial table announcement or delay the=20 >>>route refresh replies. As long as EoR is sent before EoRR there=20 >>>should be no issue right? >>> >>>Regards, >>>Keyur >>>On 1/28/14 12:06 PM, "Jakob Heitz" wrote: >>> >>>>Enke's text allows the order: BoRR, EoR, EoRR. >>>> >>>>Could we change Enke's text from >>>>"it MUST NOT send an EoRR" to >>>>"it MUST NOT send an BoRR" >>>> >>>>Thanks, >>>>Jakob. >>>> >>>>-----Original Message----- >>>>From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Keyur Patel >>>>(keyupate) >>>>Sent: Tuesday, January 28, 2014 11:51 AM >>>>To: Thomas Mangin; idr-bounces@ietf.org >>>>Cc: idr@ietf.org >>>>Subject: Re: [Idr] WG LC for=20 >>>>draft-ietf-idr-bgp-enhanced-route-refresh >>>> >>>>Hi Jacob, Thomas, >>>> >>>>Am ok with implementations delaying the servicing of route refresh=20 >>>>request. Enke's suggested text addresses the concern. >>>> >>>>Best Regards, >>>>Keyur >>>> >>>>On 1/26/14 3:39 PM, "Thomas Mangin"=20 >>>> >>>>wrote: >>>> >>>>>Damn, time to practice then :) >>>>> >>>>>Joke apart, I agree with this post. The feature should not be used=20 >>>>>( and ignored ) until the initial route exchange has been completed. >>>>> >>>>>If the session drops, I would expect the router to cancel any RR=20 >>>>>which was ongoing as the AdjRIBOut is going to be retransmitted=20 >>>>>anyway. >>>>> >>>>>Thomas >>>>> >>>>>Sent from my iPad >>>>> >>>>>> On 25 Jan 2014, at 19:48, Jakob Heitz >>>>>>wrote: >>>>>>=20 >>>>>> RFCs are written for coders "practiced" in the art". >>>>>> If anyone sends an EoRR before the adj-RIB-out is fully=20 >>>>>>populated, then it's a BUG. >>>>>> This does not need to be said. >>>>>>=20 >>>>>> Personally, I believe a route refresh request should not be=20 >>>>>>honored until GR is complete. >>>>>> Also, I don't believe a timer for the receipt of EoRR is=20 >>>>>>necessary, because the EoRR is guaranteed. >>>>>> Guaranteed means "unless the session drops first". >>>>>> -- >>>>>>=20 >>>>>> Jakob Heitz. >>>>>>=20 >>>>>> ________________________________________ >>>>>> From: Chris Hall [chris.hall@highwayman.com] >>>>>> Sent: Saturday, 25 January 2014 11:27 AM >>>>>> To: idr@ietf.org >>>>>> Cc: Jakob Heitz >>>>>> Subject: RE: [Idr] WG LC for >>>>>> draft-ietf-idr-bgp-enhanced-route-refresh >>>>>>=20 >>>>>> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): >>>>>> ... >>>>>>> Silence means don't do it. >>>>>>=20 >>>>>> Hmmm.... as a principle I'm more comfortable with "that which=20 >>>>>> isn't prohibited is permitted".... >>>>>>=20 >>>>>>> You would definitely NOT want BoRR to flush old stales. >>>>>>=20 >>>>>> ....but, given the definite requirement, and given that the=20 >>>>>> current precedent for "marking stale" does flush old stale, then=20 >>>>>> a few words for the avoidance of doubt ? >>>>>>=20 >>>>>>> Restarting the timer might be a good idea. >>>>>>=20 >>>>>> I dunno... a route which remains stale for "a long time" is, of=20 >>>>>> course, a candidate for being withdrawn: so having started a=20 >>>>>> timer the first time things are set stale, I would avoid=20 >>>>>> extending that >>>>>> -- at least for Graceful Restart, where the whole withdraw thing=20 >>>>>> has been "on-hold" since the last session failed. For=20 >>>>>> route-refresh I guess there's more of a presumption that stale=20 >>>>>> routes will be refreshed sooner or later, and in the meantime=20 >>>>>> they remain good. So if the route-refresh is (repeatedly)=20 >>>>>> restarted for some reason, perhaps it is more reasonable to=20 >>>>>> extend the flush deadline -- but avoid doing this indefinitely ? >>>>>>=20 >>>>>> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I=20 >>>>>> have built in Quagga prioritise route changes (pending changes=20 >>>>>> and any that occur during the refresh) over refresh updates. =20 >>>>>> This makes it more likely that remaining stale routes are still good= . >>>>>> But the other end cannot know that. >>>>>>=20 >>>>>> The paragraph in the draft discussing the "entire Adj-RIB-Out" >>>>>> defines that to be the entries present "at the start of the route=20 >>>>>>refresh operation", and observes that these comprise both=20 >>>>>>reachable and unreachable routes. [An "of" after "comprise" sets=20 >>>>>>teeth on edge, BTW.] I'm really not sure what this paragraph is=20 >>>>>>trying to tell me. >>>>>> The reference to unreachable routes appears to suggest that=20 >>>>>>pending withdraws should be sent as part of the refresh -- so not=20 >>>>>>left to the EoRR to implement at the end. The point at which the=20 >>>>>>EoRR is sent is defined such that it excludes any Adj-RIB-Out=20 >>>>>>entries added after the route-refresh started, but includes any=20 >>>>>>which are changed during the process. It seems reasonable to=20 >>>>>>delay any brand new reachable prefixes until after all previously=20 >>>>>>announced ones have been refreshed and the EoRR sent -- if that's the= intent here. >>>>>>Changes which occur before the refresh gets to a given entry are=20 >>>>>>pretty naturally swept up by the refresh. Changes which occur=20 >>>>>>after the refresh has gone past, could/should be deferred to after=20 >>>>>>the EoRR ? >>>>>> Does it make a difference if the change is a withdraw ? (Of=20 >>>>>>course MRAI may kick in here. Ah. MRAI and route-refresh,=20 >>>>>>there's a topic >>>>>> !) >>>>>>=20 >>>>>> I think the essence of the rule is that the EoRR should be sent=20 >>>>>>once all prefixes previously advertised to the peer as reachable=20 >>>>>>have been refreshed, ie announced or withdrawn (at least) once. >>>>>>Or, perhaps more strictly, not *before* those prefixes have *all*=20 >>>>>>been announced once -- given that the EoRR will promptly bang=20 >>>>>>un-advertised stuff on the head. Even more strictly perhaps: not=20 >>>>>>send EoRR *before* any withdraws implied by it are required or=20 >>>>>>desirable. >>>>>>=20 >>>>>> Depending on the implementation, a given sender may or may not be=20 >>>>>>able to determine the minimum set of updates required before=20 >>>>>>sending EoRR. >>>>>>=20 >>>>>> If the refresh operation takes a long time, there may be good=20 >>>>>> routeing reasons to arrange for some route changes to be sent to=20 >>>>>> the peer "early" -- that is to send announcements which do not=20 >>>>>> contribute to the refresh, but which are important enough to=20 >>>>>> warrant delaying the end of the refresh. That could be a matter=20 >>>>>> for >>>>>> recommendation(s) in the standard. >>>>>>=20 >>>>>> NB: given that the timing of the EoRR is tied to the state of the=20 >>>>>> Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. >>>>>> At the beginning of the initial update, the Restarting and=20 >>>>>> Receiving speakers have: >>>>>>=20 >>>>>> Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out >>>>>>=20 >>>>>> Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In >>>>>>=20 >>>>>> Now suppose (bonkers or otherwise) the receiving speaker sends an=20 >>>>>> RRQ part way through the initial update. The restarting speaker=20 >>>>>> responds with BoRR, everything in its Adj-RIB-Out, and EoRR --=20 >>>>>> per specification. The receiving speaker sees the EoRR, and=20 >>>>>> flushes stale. Unfortunately, if the restarting speaker has not=20 >>>>>> yet fully populated its Adj-RIB-Out, then many further routes=20 >>>>>> will be sent before the EoR falls due -- but the receiving=20 >>>>>> speaker has already flushed their tiny posteriors :-( >>>>>>=20 >>>>>> I am coming to the view that route-refresh during a Graceful=20 >>>>>> Restart initial update is a horse of a different colour altogether. >>>>>>=20 >>>>>> [So the assumption that EoRR and EoR are triggered by the same=20 >>>>>> thing was completely wrong, and I apologise for it.] >>>>>>=20 >>>>>> Chris >>>>>>=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 >>>> >>>>_______________________________________________ >>>>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 Tue Jan 28 14:56:34 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C62E1A026E; Tue, 28 Jan 2014 14:56:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5n-jUiBqkXTw; Tue, 28 Jan 2014 14:56:31 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id CF4861A0093; Tue, 28 Jan 2014 14:56:30 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-e9-52e8359ceb2b Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id AB.1B.11484.C9538E25; Tue, 28 Jan 2014 23:56:28 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0387.000; Tue, 28 Jan 2014 17:56:27 -0500 From: Jeff Tantsura To: "Keyur Patel (keyupate)" , Jakob Heitz , Thomas Mangin , "idr-bounces@ietf.org" Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPF5KdKHMolEg8TF26AxOKep0T6JqRMOhAgAGfMAD//7gu+4AAX1gA//+1BTCAAHhgAP//sQGgAA5+ToAABygAoAAmsOcAAAoIr7AAJlf4AP//r6/0gAIo+ACAAuS2AIAAU2KQ//+z84CAAFNj0P//taAAgABTAKD//7JCgAABOPmAAA4zvAA= Date: Tue, 28 Jan 2014 22:56:26 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <76961E70B3954D479F5AEC435D472874@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyuXRPuO4c0xdBBm/+WFrM2Tid1eLV7WdM Fo1bz7NZTNq2mtWBxWPK742sHv1nNzN5LFnykymAOYrLJiU1J7MstUjfLoErY/fHBtaCC9EV Bxv3MjUw7vXpYuTkkBAwkfhzei4bhC0mceHeeiCbi0NI4AijxLKeD1DOckaJ7Y0bGUGq2AQM JP5/O84CkhAR2Mco8X9dJxNIgllAUeLi3w4wW1jATeLVpOXsILaIgLtEy49JzBD2MUaJO1O9 QWwWAVWJG6v6WEBsXgFzie6PTUA1HBycQAuW3AIrZwS66PupNVDjxSVuPZnPBHGpgMSSPeeZ IWxRiZeP/7GC2KICehJtx86wQ8SVJCYtPccK0asjsWD3JzaQ8cwC1hKLLlhChLUlli18zQxx gaDEyZlPWCYwis9Csm0Wku5ZCN2zkHTPQtK9gJF1FSNHaXFqWW66keEmRmDEHZNgc9zBuOCT 5SFGaQ4WJXHeL2+dg4QE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwurjt0+tk43zQPL23k/0L +9+zF6x6J1q3bjn84Gtj5hYGthNGU6ya9ju/dZ1Rs/HYgWjRpN3t08MutOx+5Kr4fNEX9TuX FC5xBVy69IUr+JDg6s79N7Ju/Tl/MDPDMmvdqX8eDbPf3btx+tFSm/yY2GViPx+n5lu0he76 9Eio+NnPa+5fTnhF3lViKc5INNRiLipOBAC3+MRThgIAAA== Cc: "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 22:56:34 -0000 I support the wording below. Cheers, Jeff -----Original Message----- From: "keyupate@cisco.com" Date: Tuesday, January 28, 2014 1:43 PM To: "keyupate@cisco.com" , Jakob Heitz , Thomas Mangin , "idr-bounces@ietf.org" Cc: "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh >Hi Jakob,=20 > >How about the following (based on your suggestion): > >For a BGP speaker that supports the BGP Graceful Restart specified in >[RFC4724] , it MUST NOT send a BoRR for an AFI/SAFI to a neighbor >before it sends the EOR for the AFI/SAFI to the neighbor. This >procedure would help the neighbor avoid the premature cleanup of stale >routes. > > >This would help simplify receiver side implementation wrt GR and Enhanced >RR. :) > >Regards, >Keyur > >On 1/28/14 1:08 PM, "Keyur Patel (keyupate)" wrote: > >>Sure! I am saying you can simplify the implementation by simply delaying >>the servicing of the route refresh reply till the generation of an EOR. >> >>Question is do we allow the text to be flexible enough to cover the other >>case. :) >> >>Regards, >>Keyur >> >>On 1/28/14 12:56 PM, "Jakob Heitz" wrote: >> >>>Could we please simplify this a bit, not to force implementations to use >>>different stale bits? >>> >>>Thanks, >>>Jakob. >>> >>>-----Original Message----- >>>From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] >>>Sent: Tuesday, January 28, 2014 12:49 PM >>>To: Jakob Heitz; Thomas Mangin; idr-bounces@ietf.org >>>Cc: idr@ietf.org >>>Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh >>> >>> >>> >>>On 1/28/14 12:23 PM, "Jakob Heitz" wrote: >>> >>>>the order BoRR, EoR, EoRR allows this possible scenario: >>>> >>>>Suppose 2 routes exist :1.1.1.1/32, 2.2.2.2/32 The order could now be: >>>>. start session >>>>. send 1.1.1.1/32 >>>>. receive route refresh request. >>>>. send BoRR >>>>. send 2.2.2.2/32 >>>>. send EoR >>>>. send 1.1.1.1/32 >>>>. send EoRR >>>> >>>>On receipt of EoR, the receiver could delete stales, deleting >>>>1.1.1.1/32. >>> >>>Not if you use different flags/bits to mark them stale? >>> >>>Implementations could choose to always postpone the route refresh reply >>>and get the same behavior? >>> >>>Regards, >>>Keyur >>> >>>> >>>>Thanks, >>>>Jakob. >>>> >>>>-----Original Message----- >>>>From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] >>>>Sent: Tuesday, January 28, 2014 12:17 PM >>>>To: Jakob Heitz; Thomas Mangin; idr-bounces@ietf.org >>>>Cc: idr@ietf.org >>>>Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh >>>> >>>>The order: BoRR, EoR, EoRR lets an implementation do both, merge route >>>>refresh reply with an initial table announcement or delay the route >>>>refresh replies. As long as EoR is sent before EoRR there should be no >>>>issue right? >>>> >>>>Regards, >>>>Keyur >>>>On 1/28/14 12:06 PM, "Jakob Heitz" wrote: >>>> >>>>>Enke's text allows the order: BoRR, EoR, EoRR. >>>>> >>>>>Could we change Enke's text from >>>>>"it MUST NOT send an EoRR" to >>>>>"it MUST NOT send an BoRR" >>>>> >>>>>Thanks, >>>>>Jakob. >>>>> >>>>>-----Original Message----- >>>>>From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Keyur Patel >>>>>(keyupate) >>>>>Sent: Tuesday, January 28, 2014 11:51 AM >>>>>To: Thomas Mangin; idr-bounces@ietf.org >>>>>Cc: idr@ietf.org >>>>>Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh >>>>> >>>>>Hi Jacob, Thomas, >>>>> >>>>>Am ok with implementations delaying the servicing of route refresh >>>>>request. Enke's suggested text addresses the concern. >>>>> >>>>>Best Regards, >>>>>Keyur >>>>> >>>>>On 1/26/14 3:39 PM, "Thomas Mangin" >>>>>wrote: >>>>> >>>>>>Damn, time to practice then :) >>>>>> >>>>>>Joke apart, I agree with this post. The feature should not be used ( >>>>>>and ignored ) until the initial route exchange has been completed. >>>>>> >>>>>>If the session drops, I would expect the router to cancel any RR >>>>>>which was ongoing as the AdjRIBOut is going to be retransmitted >>>>>>anyway. >>>>>> >>>>>>Thomas >>>>>> >>>>>>Sent from my iPad >>>>>> >>>>>>> On 25 Jan 2014, at 19:48, Jakob Heitz >>>>>>>wrote: >>>>>>>=20 >>>>>>> RFCs are written for coders "practiced" in the art". >>>>>>> If anyone sends an EoRR before the adj-RIB-out is fully populated, >>>>>>>then it's a BUG. >>>>>>> This does not need to be said. >>>>>>>=20 >>>>>>> Personally, I believe a route refresh request should not be honored >>>>>>>until GR is complete. >>>>>>> Also, I don't believe a timer for the receipt of EoRR is necessary, >>>>>>>because the EoRR is guaranteed. >>>>>>> Guaranteed means "unless the session drops first". >>>>>>> -- >>>>>>>=20 >>>>>>> Jakob Heitz. >>>>>>>=20 >>>>>>> ________________________________________ >>>>>>> From: Chris Hall [chris.hall@highwayman.com] >>>>>>> Sent: Saturday, 25 January 2014 11:27 AM >>>>>>> To: idr@ietf.org >>>>>>> Cc: Jakob Heitz >>>>>>> Subject: RE: [Idr] WG LC for >>>>>>> draft-ietf-idr-bgp-enhanced-route-refresh >>>>>>>=20 >>>>>>> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): >>>>>>> ... >>>>>>>> Silence means don't do it. >>>>>>>=20 >>>>>>> Hmmm.... as a principle I'm more comfortable with "that which isn't >>>>>>> prohibited is permitted".... >>>>>>>=20 >>>>>>>> You would definitely NOT want BoRR to flush old stales. >>>>>>>=20 >>>>>>> ....but, given the definite requirement, and given that the current >>>>>>> precedent for "marking stale" does flush old stale, then a few >>>>>>> words for the avoidance of doubt ? >>>>>>>=20 >>>>>>>> Restarting the timer might be a good idea. >>>>>>>=20 >>>>>>> I dunno... a route which remains stale for "a long time" is, of >>>>>>> course, a candidate for being withdrawn: so having started a timer >>>>>>> the first time things are set stale, I would avoid extending that >>>>>>> -- at least for Graceful Restart, where the whole withdraw thing >>>>>>> has been "on-hold" since the last session failed. For >>>>>>> route-refresh I guess there's more of a presumption that stale >>>>>>> routes will be refreshed sooner or later, and in the meantime they >>>>>>> remain good. So if the route-refresh is (repeatedly) restarted for >>>>>>> some reason, perhaps it is more reasonable to extend the flush >>>>>>> deadline -- but avoid doing this indefinitely ? >>>>>>>=20 >>>>>>> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I >>>>>>> have built in Quagga prioritise route changes (pending changes and >>>>>>> any that occur during the refresh) over refresh updates. This >>>>>>> makes it more likely that remaining stale routes are still good. >>>>>>> But the other end cannot know that. >>>>>>>=20 >>>>>>> The paragraph in the draft discussing the "entire Adj-RIB-Out" >>>>>>> defines that to be the entries present "at the start of the route >>>>>>>refresh operation", and observes that these comprise both reachable >>>>>>>and unreachable routes. [An "of" after "comprise" sets teeth on >>>>>>>edge, BTW.] I'm really not sure what this paragraph is trying to >>>>>>>tell me. >>>>>>> The reference to unreachable routes appears to suggest that pending >>>>>>>withdraws should be sent as part of the refresh -- so not left to >>>>>>>the EoRR to implement at the end. The point at which the EoRR is >>>>>>>sent is defined such that it excludes any Adj-RIB-Out entries added >>>>>>>after the route-refresh started, but includes any which are changed >>>>>>>during the process. It seems reasonable to delay any brand new >>>>>>>reachable prefixes until after all previously announced ones have >>>>>>>been refreshed and the EoRR sent -- if that's the intent here. >>>>>>>Changes which occur before the refresh gets to a given entry are >>>>>>>pretty naturally swept up by the refresh. Changes which occur after >>>>>>>the refresh has gone past, could/should be deferred to after the >>>>>>>EoRR >>>>>>>? >>>>>>> Does it make a difference if the change is a withdraw ? (Of course >>>>>>>MRAI may kick in here. Ah. MRAI and route-refresh, there's a topic >>>>>>> !) >>>>>>>=20 >>>>>>> I think the essence of the rule is that the EoRR should be sent >>>>>>>once all prefixes previously advertised to the peer as reachable >>>>>>>have been refreshed, ie announced or withdrawn (at least) once. >>>>>>>Or, perhaps more strictly, not *before* those prefixes have *all* >>>>>>>been announced once -- given that the EoRR will promptly bang >>>>>>>un-advertised stuff on the head. Even more strictly perhaps: not >>>>>>>send EoRR *before* any withdraws implied by it are required or >>>>>>>desirable. >>>>>>>=20 >>>>>>> Depending on the implementation, a given sender may or may not be >>>>>>>able to determine the minimum set of updates required before sending >>>>>>>EoRR. >>>>>>>=20 >>>>>>> If the refresh operation takes a long time, there may be good >>>>>>> routeing reasons to arrange for some route changes to be sent to >>>>>>> the peer "early" -- that is to send announcements which do not >>>>>>> contribute to the refresh, but which are important enough to >>>>>>> warrant delaying the end of the refresh. That could be a matter >>>>>>> for >>>>>>> recommendation(s) in the standard. >>>>>>>=20 >>>>>>> NB: given that the timing of the EoRR is tied to the state of the >>>>>>> Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. >>>>>>> At the beginning of the initial update, the Restarting and >>>>>>> Receiving speakers have: >>>>>>>=20 >>>>>>> Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out >>>>>>>=20 >>>>>>> Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In >>>>>>>=20 >>>>>>> Now suppose (bonkers or otherwise) the receiving speaker sends an >>>>>>> RRQ part way through the initial update. The restarting speaker >>>>>>> responds with BoRR, everything in its Adj-RIB-Out, and EoRR -- per >>>>>>> specification. The receiving speaker sees the EoRR, and flushes >>>>>>> stale. Unfortunately, if the restarting speaker has not yet fully >>>>>>> populated its Adj-RIB-Out, then many further routes will be sent >>>>>>> before the EoR falls due -- but the receiving speaker has already >>>>>>> flushed their tiny posteriors :-( >>>>>>>=20 >>>>>>> I am coming to the view that route-refresh during a Graceful >>>>>>> Restart initial update is a horse of a different colour altogether. >>>>>>>=20 >>>>>>> [So the assumption that EoRR and EoR are triggered by the same >>>>>>> thing was completely wrong, and I apologise for it.] >>>>>>>=20 >>>>>>> Chris >>>>>>>=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 >>>>> >>>>>_______________________________________________ >>>>>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 shares@ndzh.com Tue Jan 28 16:53:02 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 953C61A0378; Tue, 28 Jan 2014 16:53:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnyRvyKn1vjq; Tue, 28 Jan 2014 16:52:59 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 67B4A1A03C4; Tue, 28 Jan 2014 16:52:59 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Jeff Tantsura'" , "'Keyur Patel \(keyupate\)'" , "'Jakob Heitz'" , "'Thomas Mangin'" , References: In-Reply-To: Date: Tue, 28 Jan 2014 19:52:42 -0500 Message-ID: <010801cf1c8c$6b1a0420$414e0c60$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJwxkzzhYFPY59L2AscNsp0KShvnplXi/NA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 00:53:02 -0000 Any other comments? (support/discussion accepted) Sue Hares PS - Keyur - spin a draft with this change and end it to me. -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jeff Tantsura Sent: Tuesday, January 28, 2014 5:56 PM To: Keyur Patel (keyupate); Jakob Heitz; Thomas Mangin; idr-bounces@ietf.org Cc: idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh I support the wording below. Cheers, Jeff -----Original Message----- From: "keyupate@cisco.com" Date: Tuesday, January 28, 2014 1:43 PM To: "keyupate@cisco.com" , Jakob Heitz , Thomas Mangin , "idr-bounces@ietf.org" Cc: "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh >Hi Jakob, > >How about the following (based on your suggestion): > >For a BGP speaker that supports the BGP Graceful Restart specified in >[RFC4724] , it MUST NOT send a BoRR for an AFI/SAFI to a neighbor >before it sends the EOR for the AFI/SAFI to the neighbor. This >procedure would help the neighbor avoid the premature cleanup of stale >routes. > > >This would help simplify receiver side implementation wrt GR and >Enhanced RR. :) > >Regards, >Keyur > >On 1/28/14 1:08 PM, "Keyur Patel (keyupate)" wrote: > >>Sure! I am saying you can simplify the implementation by simply >>delaying the servicing of the route refresh reply till the generation of an EOR. >> >>Question is do we allow the text to be flexible enough to cover the >>other case. :) >> >>Regards, >>Keyur >> >>On 1/28/14 12:56 PM, "Jakob Heitz" wrote: >> >>>Could we please simplify this a bit, not to force implementations to >>>use different stale bits? >>> >>>Thanks, >>>Jakob. >>> >>>-----Original Message----- >>>From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] >>>Sent: Tuesday, January 28, 2014 12:49 PM >>>To: Jakob Heitz; Thomas Mangin; idr-bounces@ietf.org >>>Cc: idr@ietf.org >>>Subject: Re: [Idr] WG LC for >>>draft-ietf-idr-bgp-enhanced-route-refresh >>> >>> >>> >>>On 1/28/14 12:23 PM, "Jakob Heitz" wrote: >>> >>>>the order BoRR, EoR, EoRR allows this possible scenario: >>>> >>>>Suppose 2 routes exist :1.1.1.1/32, 2.2.2.2/32 The order could now be: >>>>. start session >>>>. send 1.1.1.1/32 >>>>. receive route refresh request. >>>>. send BoRR >>>>. send 2.2.2.2/32 >>>>. send EoR >>>>. send 1.1.1.1/32 >>>>. send EoRR >>>> >>>>On receipt of EoR, the receiver could delete stales, deleting >>>>1.1.1.1/32. >>> >>>Not if you use different flags/bits to mark them stale? >>> >>>Implementations could choose to always postpone the route refresh >>>reply and get the same behavior? >>> >>>Regards, >>>Keyur >>> >>>> >>>>Thanks, >>>>Jakob. >>>> >>>>-----Original Message----- >>>>From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] >>>>Sent: Tuesday, January 28, 2014 12:17 PM >>>>To: Jakob Heitz; Thomas Mangin; idr-bounces@ietf.org >>>>Cc: idr@ietf.org >>>>Subject: Re: [Idr] WG LC for >>>>draft-ietf-idr-bgp-enhanced-route-refresh >>>> >>>>The order: BoRR, EoR, EoRR lets an implementation do both, merge >>>>route refresh reply with an initial table announcement or delay the >>>>route refresh replies. As long as EoR is sent before EoRR there >>>>should be no issue right? >>>> >>>>Regards, >>>>Keyur >>>>On 1/28/14 12:06 PM, "Jakob Heitz" wrote: >>>> >>>>>Enke's text allows the order: BoRR, EoR, EoRR. >>>>> >>>>>Could we change Enke's text from >>>>>"it MUST NOT send an EoRR" to >>>>>"it MUST NOT send an BoRR" >>>>> >>>>>Thanks, >>>>>Jakob. >>>>> >>>>>-----Original Message----- >>>>>From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Keyur Patel >>>>>(keyupate) >>>>>Sent: Tuesday, January 28, 2014 11:51 AM >>>>>To: Thomas Mangin; idr-bounces@ietf.org >>>>>Cc: idr@ietf.org >>>>>Subject: Re: [Idr] WG LC for >>>>>draft-ietf-idr-bgp-enhanced-route-refresh >>>>> >>>>>Hi Jacob, Thomas, >>>>> >>>>>Am ok with implementations delaying the servicing of route refresh >>>>>request. Enke's suggested text addresses the concern. >>>>> >>>>>Best Regards, >>>>>Keyur >>>>> >>>>>On 1/26/14 3:39 PM, "Thomas Mangin" >>>>> >>>>>wrote: >>>>> >>>>>>Damn, time to practice then :) >>>>>> >>>>>>Joke apart, I agree with this post. The feature should not be used >>>>>>( and ignored ) until the initial route exchange has been completed. >>>>>> >>>>>>If the session drops, I would expect the router to cancel any RR >>>>>>which was ongoing as the AdjRIBOut is going to be retransmitted >>>>>>anyway. >>>>>> >>>>>>Thomas >>>>>> >>>>>>Sent from my iPad >>>>>> >>>>>>> On 25 Jan 2014, at 19:48, Jakob Heitz >>>>>>>wrote: >>>>>>> >>>>>>> RFCs are written for coders "practiced" in the art". >>>>>>> If anyone sends an EoRR before the adj-RIB-out is fully >>>>>>>populated, then it's a BUG. >>>>>>> This does not need to be said. >>>>>>> >>>>>>> Personally, I believe a route refresh request should not be >>>>>>>honored until GR is complete. >>>>>>> Also, I don't believe a timer for the receipt of EoRR is >>>>>>>necessary, because the EoRR is guaranteed. >>>>>>> Guaranteed means "unless the session drops first". >>>>>>> -- >>>>>>> >>>>>>> Jakob Heitz. >>>>>>> >>>>>>> ________________________________________ >>>>>>> From: Chris Hall [chris.hall@highwayman.com] >>>>>>> Sent: Saturday, 25 January 2014 11:27 AM >>>>>>> To: idr@ietf.org >>>>>>> Cc: Jakob Heitz >>>>>>> Subject: RE: [Idr] WG LC for >>>>>>> draft-ietf-idr-bgp-enhanced-route-refresh >>>>>>> >>>>>>> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): >>>>>>> ... >>>>>>>> Silence means don't do it. >>>>>>> >>>>>>> Hmmm.... as a principle I'm more comfortable with "that which >>>>>>> isn't prohibited is permitted".... >>>>>>> >>>>>>>> You would definitely NOT want BoRR to flush old stales. >>>>>>> >>>>>>> ....but, given the definite requirement, and given that the >>>>>>> current precedent for "marking stale" does flush old stale, then >>>>>>> a few words for the avoidance of doubt ? >>>>>>> >>>>>>>> Restarting the timer might be a good idea. >>>>>>> >>>>>>> I dunno... a route which remains stale for "a long time" is, of >>>>>>> course, a candidate for being withdrawn: so having started a >>>>>>> timer the first time things are set stale, I would avoid >>>>>>> extending that >>>>>>> -- at least for Graceful Restart, where the whole withdraw thing >>>>>>> has been "on-hold" since the last session failed. For >>>>>>> route-refresh I guess there's more of a presumption that stale >>>>>>> routes will be refreshed sooner or later, and in the meantime >>>>>>> they remain good. So if the route-refresh is (repeatedly) >>>>>>> restarted for some reason, perhaps it is more reasonable to >>>>>>> extend the flush deadline -- but avoid doing this indefinitely ? >>>>>>> >>>>>>> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I >>>>>>> have built in Quagga prioritise route changes (pending changes >>>>>>> and any that occur during the refresh) over refresh updates. >>>>>>> This makes it more likely that remaining stale routes are still good. >>>>>>> But the other end cannot know that. >>>>>>> >>>>>>> The paragraph in the draft discussing the "entire Adj-RIB-Out" >>>>>>> defines that to be the entries present "at the start of the >>>>>>>route refresh operation", and observes that these comprise both >>>>>>>reachable and unreachable routes. [An "of" after "comprise" sets >>>>>>>teeth on edge, BTW.] I'm really not sure what this paragraph is >>>>>>>trying to tell me. >>>>>>> The reference to unreachable routes appears to suggest that >>>>>>>pending withdraws should be sent as part of the refresh -- so not >>>>>>>left to the EoRR to implement at the end. The point at which the >>>>>>>EoRR is sent is defined such that it excludes any Adj-RIB-Out >>>>>>>entries added after the route-refresh started, but includes any >>>>>>>which are changed during the process. It seems reasonable to >>>>>>>delay any brand new reachable prefixes until after all previously >>>>>>>announced ones have been refreshed and the EoRR sent -- if that's the intent here. >>>>>>>Changes which occur before the refresh gets to a given entry are >>>>>>>pretty naturally swept up by the refresh. Changes which occur >>>>>>>after the refresh has gone past, could/should be deferred to >>>>>>>after the EoRR ? >>>>>>> Does it make a difference if the change is a withdraw ? (Of >>>>>>>course MRAI may kick in here. Ah. MRAI and route-refresh, >>>>>>>there's a topic >>>>>>> !) >>>>>>> >>>>>>> I think the essence of the rule is that the EoRR should be sent >>>>>>>once all prefixes previously advertised to the peer as reachable >>>>>>>have been refreshed, ie announced or withdrawn (at least) once. >>>>>>>Or, perhaps more strictly, not *before* those prefixes have >>>>>>>*all* been announced once -- given that the EoRR will promptly >>>>>>>bang un-advertised stuff on the head. Even more strictly >>>>>>>perhaps: not send EoRR *before* any withdraws implied by it are >>>>>>>required or desirable. >>>>>>> >>>>>>> Depending on the implementation, a given sender may or may not >>>>>>>be able to determine the minimum set of updates required before >>>>>>>sending EoRR. >>>>>>> >>>>>>> If the refresh operation takes a long time, there may be good >>>>>>> routeing reasons to arrange for some route changes to be sent to >>>>>>> the peer "early" -- that is to send announcements which do not >>>>>>> contribute to the refresh, but which are important enough to >>>>>>> warrant delaying the end of the refresh. That could be a matter >>>>>>> for >>>>>>> recommendation(s) in the standard. >>>>>>> >>>>>>> NB: given that the timing of the EoRR is tied to the state of >>>>>>> the Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. >>>>>>> At the beginning of the initial update, the Restarting and >>>>>>> Receiving speakers have: >>>>>>> >>>>>>> Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out >>>>>>> >>>>>>> Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In >>>>>>> >>>>>>> Now suppose (bonkers or otherwise) the receiving speaker sends >>>>>>> an RRQ part way through the initial update. The restarting >>>>>>> speaker responds with BoRR, everything in its Adj-RIB-Out, and >>>>>>> EoRR -- per specification. The receiving speaker sees the EoRR, >>>>>>> and flushes stale. Unfortunately, if the restarting speaker has >>>>>>> not yet fully populated its Adj-RIB-Out, then many further >>>>>>> routes will be sent before the EoR falls due -- but the >>>>>>> receiving speaker has already flushed their tiny posteriors :-( >>>>>>> >>>>>>> I am coming to the view that route-refresh during a Graceful >>>>>>> Restart initial update is a horse of a different colour altogether. >>>>>>> >>>>>>> [So the assumption that EoRR and EoR are triggered by the same >>>>>>> thing was completely wrong, and I apologise for it.] >>>>>>> >>>>>>> Chris >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 > >_______________________________________________ >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 sairay@cisco.com Tue Jan 28 17:03:37 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B24BE1A044C; Tue, 28 Jan 2014 17:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0aKAVW6ykVi; Tue, 28 Jan 2014 17:03:35 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 2355E1A037C; Tue, 28 Jan 2014 17:03:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13458; q=dns/txt; s=iport; t=1390957412; x=1392167012; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=PPGP2QHC69ATa4QFBobyQ4WoMD9hNrogqhLBWCM2EA4=; b=JehkcMfNx+p2Fz5mOm8unH68ESgUyg2VTTlwPh2WpqtFHIYnxIJIYpQ6 zVCVfXIMVNF+QJmvTu7rM8CwBDqo7kFrY7lbCAPOgrqVOLMpfLFxrZJVz djrt+WkkJItURmT/5ZUU/olsh5co1XSrgGa3F+E/mNK8v5EqoNZMj/kG4 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFACVS6FKtJXG+/2dsb2JhbABagww4Vr0FgQ8WdIIlAQEBBAEBATc0CwwEAgEIDgMDAQEBAQoUCQcnCxQJCAIEAQ0FCId9DakeoFcTBI5OMQcGgx6BFAEDlECWB4Mtgio X-IronPort-AV: E=Sophos;i="4.95,739,1384300800"; d="scan'208";a="16252548" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-7.cisco.com with ESMTP; 29 Jan 2014 01:03:31 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0T13V7L018031 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Jan 2014 01:03:31 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.24]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Tue, 28 Jan 2014 19:03:31 -0600 From: "Saikat Ray (sairay)" To: Susan Hares , "'Jeff Tantsura'" , "Keyur Patel (keyupate)" , "'Jakob Heitz'" , "'Thomas Mangin'" , "idr-bounces@ietf.org" Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPF5Kdim6y2NtdXEOlCixBVCgqkZqRnDwAgAFEnwCAAAwAgIAAC4cAgAARhoCAABveAIAABfyAgAAe+ICAABsuAIABU5kAgAAEDoCAAX73AIAABbuAgAHS7QCAAuS1AIAABIUAgAAC0YCAAAG5gIAAB0kAgAACCYCAAAM5gIAACciAgAAUgwCAACB8AP//m/cw Date: Wed, 29 Jan 2014 01:03:30 +0000 Message-ID: <8ED5B0B0F5B4854A912480C1521F973A11AFBD56@xmb-rcd-x13.cisco.com> References: <010801cf1c8c$6b1a0420$414e0c60$@ndzh.com> In-Reply-To: <010801cf1c8c$6b1a0420$414e0c60$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.166.25] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 01:03:37 -0000 The draft should add a line mandating the actual semantics (instead of/in a= ddition to the procedures of mark-and-sweep). Something along the line:=20 "Any route for which no update has been sent between a BoRR and the followi= ng EoRR MUST be considered withdrawn by both the sender and the receiver." The rest is really implementation (how to handle nested BoRR/EoRR or GR EoR= , etc.), IMHO. I support the draft, BTW. -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, January 28, 2014 4:53 PM To: 'Jeff Tantsura'; Keyur Patel (keyupate); 'Jakob Heitz'; 'Thomas Mangin'= ; idr-bounces@ietf.org Cc: idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Any other comments? (support/discussion accepted) Sue Hares PS - Keyur - spin a draft with this change and end it to me.=20 -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jeff Tantsura Sent: Tuesday, January 28, 2014 5:56 PM To: Keyur Patel (keyupate); Jakob Heitz; Thomas Mangin; idr-bounces@ietf.or= g Cc: idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh I support the wording below. Cheers, Jeff -----Original Message----- From: "keyupate@cisco.com" Date: Tuesday, January 28, 2014 1:43 PM To: "keyupate@cisco.com" , Jakob Heitz , Thomas Mangin , "idr-bounces@= ietf.org" Cc: "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh >Hi Jakob, > >How about the following (based on your suggestion): > >For a BGP speaker that supports the BGP Graceful Restart specified in=20 >[RFC4724] , it MUST NOT send a BoRR for an AFI/SAFI to a neighbor=20 >before it sends the EOR for the AFI/SAFI to the neighbor. This=20 >procedure would help the neighbor avoid the premature cleanup of stale=20 >routes. > > >This would help simplify receiver side implementation wrt GR and=20 >Enhanced RR. :) > >Regards, >Keyur > >On 1/28/14 1:08 PM, "Keyur Patel (keyupate)" wrote: > >>Sure! I am saying you can simplify the implementation by simply=20 >>delaying the servicing of the route refresh reply till the generation=20 >>of an EOR. >> >>Question is do we allow the text to be flexible enough to cover the=20 >>other case. :) >> >>Regards, >>Keyur >> >>On 1/28/14 12:56 PM, "Jakob Heitz" wrote: >> >>>Could we please simplify this a bit, not to force implementations to=20 >>>use different stale bits? >>> >>>Thanks, >>>Jakob. >>> >>>-----Original Message----- >>>From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] >>>Sent: Tuesday, January 28, 2014 12:49 PM >>>To: Jakob Heitz; Thomas Mangin; idr-bounces@ietf.org >>>Cc: idr@ietf.org >>>Subject: Re: [Idr] WG LC for >>>draft-ietf-idr-bgp-enhanced-route-refresh >>> >>> >>> >>>On 1/28/14 12:23 PM, "Jakob Heitz" wrote: >>> >>>>the order BoRR, EoR, EoRR allows this possible scenario: >>>> >>>>Suppose 2 routes exist :1.1.1.1/32, 2.2.2.2/32 The order could now be: >>>>. start session >>>>. send 1.1.1.1/32 >>>>. receive route refresh request. >>>>. send BoRR >>>>. send 2.2.2.2/32 >>>>. send EoR >>>>. send 1.1.1.1/32 >>>>. send EoRR >>>> >>>>On receipt of EoR, the receiver could delete stales, deleting=20 >>>>1.1.1.1/32. >>> >>>Not if you use different flags/bits to mark them stale? >>> >>>Implementations could choose to always postpone the route refresh=20 >>>reply and get the same behavior? >>> >>>Regards, >>>Keyur >>> >>>> >>>>Thanks, >>>>Jakob. >>>> >>>>-----Original Message----- >>>>From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] >>>>Sent: Tuesday, January 28, 2014 12:17 PM >>>>To: Jakob Heitz; Thomas Mangin; idr-bounces@ietf.org >>>>Cc: idr@ietf.org >>>>Subject: Re: [Idr] WG LC for >>>>draft-ietf-idr-bgp-enhanced-route-refresh >>>> >>>>The order: BoRR, EoR, EoRR lets an implementation do both, merge=20 >>>>route refresh reply with an initial table announcement or delay the=20 >>>>route refresh replies. As long as EoR is sent before EoRR there=20 >>>>should be no issue right? >>>> >>>>Regards, >>>>Keyur >>>>On 1/28/14 12:06 PM, "Jakob Heitz" wrote: >>>> >>>>>Enke's text allows the order: BoRR, EoR, EoRR. >>>>> >>>>>Could we change Enke's text from >>>>>"it MUST NOT send an EoRR" to >>>>>"it MUST NOT send an BoRR" >>>>> >>>>>Thanks, >>>>>Jakob. >>>>> >>>>>-----Original Message----- >>>>>From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Keyur Patel >>>>>(keyupate) >>>>>Sent: Tuesday, January 28, 2014 11:51 AM >>>>>To: Thomas Mangin; idr-bounces@ietf.org >>>>>Cc: idr@ietf.org >>>>>Subject: Re: [Idr] WG LC for >>>>>draft-ietf-idr-bgp-enhanced-route-refresh >>>>> >>>>>Hi Jacob, Thomas, >>>>> >>>>>Am ok with implementations delaying the servicing of route refresh=20 >>>>>request. Enke's suggested text addresses the concern. >>>>> >>>>>Best Regards, >>>>>Keyur >>>>> >>>>>On 1/26/14 3:39 PM, "Thomas Mangin"=20 >>>>> >>>>>wrote: >>>>> >>>>>>Damn, time to practice then :) >>>>>> >>>>>>Joke apart, I agree with this post. The feature should not be used=20 >>>>>>( and ignored ) until the initial route exchange has been completed. >>>>>> >>>>>>If the session drops, I would expect the router to cancel any RR=20 >>>>>>which was ongoing as the AdjRIBOut is going to be retransmitted=20 >>>>>>anyway. >>>>>> >>>>>>Thomas >>>>>> >>>>>>Sent from my iPad >>>>>> >>>>>>> On 25 Jan 2014, at 19:48, Jakob Heitz >>>>>>>wrote: >>>>>>>=20 >>>>>>> RFCs are written for coders "practiced" in the art". >>>>>>> If anyone sends an EoRR before the adj-RIB-out is fully=20 >>>>>>>populated, then it's a BUG. >>>>>>> This does not need to be said. >>>>>>>=20 >>>>>>> Personally, I believe a route refresh request should not be=20 >>>>>>>honored until GR is complete. >>>>>>> Also, I don't believe a timer for the receipt of EoRR is=20 >>>>>>>necessary, because the EoRR is guaranteed. >>>>>>> Guaranteed means "unless the session drops first". >>>>>>> -- >>>>>>>=20 >>>>>>> Jakob Heitz. >>>>>>>=20 >>>>>>> ________________________________________ >>>>>>> From: Chris Hall [chris.hall@highwayman.com] >>>>>>> Sent: Saturday, 25 January 2014 11:27 AM >>>>>>> To: idr@ietf.org >>>>>>> Cc: Jakob Heitz >>>>>>> Subject: RE: [Idr] WG LC for >>>>>>> draft-ietf-idr-bgp-enhanced-route-refresh >>>>>>>=20 >>>>>>> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): >>>>>>> ... >>>>>>>> Silence means don't do it. >>>>>>>=20 >>>>>>> Hmmm.... as a principle I'm more comfortable with "that which=20 >>>>>>> isn't prohibited is permitted".... >>>>>>>=20 >>>>>>>> You would definitely NOT want BoRR to flush old stales. >>>>>>>=20 >>>>>>> ....but, given the definite requirement, and given that the=20 >>>>>>> current precedent for "marking stale" does flush old stale, then=20 >>>>>>> a few words for the avoidance of doubt ? >>>>>>>=20 >>>>>>>> Restarting the timer might be a good idea. >>>>>>>=20 >>>>>>> I dunno... a route which remains stale for "a long time" is, of=20 >>>>>>> course, a candidate for being withdrawn: so having started a=20 >>>>>>> timer the first time things are set stale, I would avoid=20 >>>>>>> extending that >>>>>>> -- at least for Graceful Restart, where the whole withdraw thing=20 >>>>>>> has been "on-hold" since the last session failed. For=20 >>>>>>> route-refresh I guess there's more of a presumption that stale=20 >>>>>>> routes will be refreshed sooner or later, and in the meantime=20 >>>>>>> they remain good. So if the route-refresh is (repeatedly)=20 >>>>>>> restarted for some reason, perhaps it is more reasonable to=20 >>>>>>> extend the flush deadline -- but avoid doing this indefinitely ? >>>>>>>=20 >>>>>>> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I=20 >>>>>>> have built in Quagga prioritise route changes (pending changes=20 >>>>>>> and any that occur during the refresh) over refresh updates. >>>>>>> This makes it more likely that remaining stale routes are still good. >>>>>>> But the other end cannot know that. >>>>>>>=20 >>>>>>> The paragraph in the draft discussing the "entire Adj-RIB-Out" >>>>>>> defines that to be the entries present "at the start of the=20 >>>>>>>route refresh operation", and observes that these comprise both=20 >>>>>>>reachable and unreachable routes. [An "of" after "comprise" sets=20 >>>>>>>teeth on edge, BTW.] I'm really not sure what this paragraph is=20 >>>>>>>trying to tell me. >>>>>>> The reference to unreachable routes appears to suggest that=20 >>>>>>>pending withdraws should be sent as part of the refresh -- so not=20 >>>>>>>left to the EoRR to implement at the end. The point at which the=20 >>>>>>>EoRR is sent is defined such that it excludes any Adj-RIB-Out=20 >>>>>>>entries added after the route-refresh started, but includes any=20 >>>>>>>which are changed during the process. It seems reasonable to=20 >>>>>>>delay any brand new reachable prefixes until after all previously=20 >>>>>>>announced ones have been refreshed and the EoRR sent -- if that's=20 >>>>>>>the intent here. >>>>>>>Changes which occur before the refresh gets to a given entry are=20 >>>>>>>pretty naturally swept up by the refresh. Changes which occur=20 >>>>>>>after the refresh has gone past, could/should be deferred to=20 >>>>>>>after the EoRR ? >>>>>>> Does it make a difference if the change is a withdraw ? (Of=20 >>>>>>>course MRAI may kick in here. Ah. MRAI and route-refresh,=20 >>>>>>>there's a topic >>>>>>> !) >>>>>>>=20 >>>>>>> I think the essence of the rule is that the EoRR should be sent=20 >>>>>>>once all prefixes previously advertised to the peer as reachable=20 >>>>>>>have been refreshed, ie announced or withdrawn (at least) once. >>>>>>>Or, perhaps more strictly, not *before* those prefixes have >>>>>>>*all* been announced once -- given that the EoRR will promptly=20 >>>>>>>bang un-advertised stuff on the head. Even more strictly >>>>>>>perhaps: not send EoRR *before* any withdraws implied by it are=20 >>>>>>>required or desirable. >>>>>>>=20 >>>>>>> Depending on the implementation, a given sender may or may not=20 >>>>>>>be able to determine the minimum set of updates required before=20 >>>>>>>sending EoRR. >>>>>>>=20 >>>>>>> If the refresh operation takes a long time, there may be good=20 >>>>>>> routeing reasons to arrange for some route changes to be sent to=20 >>>>>>> the peer "early" -- that is to send announcements which do not=20 >>>>>>> contribute to the refresh, but which are important enough to=20 >>>>>>> warrant delaying the end of the refresh. That could be a matter=20 >>>>>>> for >>>>>>> recommendation(s) in the standard. >>>>>>>=20 >>>>>>> NB: given that the timing of the EoRR is tied to the state of=20 >>>>>>> the Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. >>>>>>> At the beginning of the initial update, the Restarting and=20 >>>>>>> Receiving speakers have: >>>>>>>=20 >>>>>>> Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out >>>>>>>=20 >>>>>>> Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In >>>>>>>=20 >>>>>>> Now suppose (bonkers or otherwise) the receiving speaker sends=20 >>>>>>> an RRQ part way through the initial update. The restarting=20 >>>>>>> speaker responds with BoRR, everything in its Adj-RIB-Out, and=20 >>>>>>> EoRR -- per specification. The receiving speaker sees the EoRR,=20 >>>>>>> and flushes stale. Unfortunately, if the restarting speaker has=20 >>>>>>> not yet fully populated its Adj-RIB-Out, then many further=20 >>>>>>> routes will be sent before the EoR falls due -- but the=20 >>>>>>> receiving speaker has already flushed their tiny posteriors :-( >>>>>>>=20 >>>>>>> I am coming to the view that route-refresh during a Graceful=20 >>>>>>> Restart initial update is a horse of a different colour altogether. >>>>>>>=20 >>>>>>> [So the assumption that EoRR and EoR are triggered by the same=20 >>>>>>> thing was completely wrong, and I apologise for it.] >>>>>>>=20 >>>>>>> Chris >>>>>>>=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 >>>>> >>>>>_______________________________________________ >>>>>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 _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From shares@ndzh.com Tue Jan 28 17:21:16 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEDB31A0484; Tue, 28 Jan 2014 17:21:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TXvMB4BSx-e; Tue, 28 Jan 2014 17:21:14 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFC21A047E; Tue, 28 Jan 2014 17:21:14 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Saikat Ray \(sairay\)'" , "'Jeff Tantsura'" , "'Keyur Patel \(keyupate\)'" , "'Jakob Heitz'" , "'Thomas Mangin'" , References: <010801cf1c8c$6b1a0420$414e0c60$@ndzh.com> <8ED5B0B0F5B4854A912480C1521F973A11AFBD56@xmb-rcd-x13.cisco.com> In-Reply-To: <8ED5B0B0F5B4854A912480C1521F973A11AFBD56@xmb-rcd-x13.cisco.com> Date: Tue, 28 Jan 2014 20:21:01 -0500 Message-ID: <013501cf1c90$5fd840f0$1f88c2d0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIVQdHzpYvkm0BCTmodJao1+Yeh6wJwxkzzAi3c/cwCTiJCLZnXNiCg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 01:21:17 -0000 Saikat: Thanks for the input, and the discussion. Just to be clear - We are at WG LC. We'll let Keyur take feedback for a new version. And then let everyone review the changes. Sue -----Original Message----- From: Saikat Ray (sairay) [mailto:sairay@cisco.com] Sent: Tuesday, January 28, 2014 8:04 PM To: Susan Hares; 'Jeff Tantsura'; Keyur Patel (keyupate); 'Jakob Heitz'; 'Thomas Mangin'; idr-bounces@ietf.org Cc: idr@ietf.org Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh The draft should add a line mandating the actual semantics (instead of/in addition to the procedures of mark-and-sweep). Something along the line: "Any route for which no update has been sent between a BoRR and the following EoRR MUST be considered withdrawn by both the sender and the receiver." The rest is really implementation (how to handle nested BoRR/EoRR or GR EoR, etc.), IMHO. I support the draft, BTW. -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, January 28, 2014 4:53 PM To: 'Jeff Tantsura'; Keyur Patel (keyupate); 'Jakob Heitz'; 'Thomas Mangin'; idr-bounces@ietf.org Cc: idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Any other comments? (support/discussion accepted) Sue Hares PS - Keyur - spin a draft with this change and end it to me. -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jeff Tantsura Sent: Tuesday, January 28, 2014 5:56 PM To: Keyur Patel (keyupate); Jakob Heitz; Thomas Mangin; idr-bounces@ietf.org Cc: idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh I support the wording below. Cheers, Jeff -----Original Message----- From: "keyupate@cisco.com" Date: Tuesday, January 28, 2014 1:43 PM To: "keyupate@cisco.com" , Jakob Heitz , Thomas Mangin , "idr-bounces@ietf.org" Cc: "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh >Hi Jakob, > >How about the following (based on your suggestion): > >For a BGP speaker that supports the BGP Graceful Restart specified in >[RFC4724] , it MUST NOT send a BoRR for an AFI/SAFI to a neighbor >before it sends the EOR for the AFI/SAFI to the neighbor. This >procedure would help the neighbor avoid the premature cleanup of stale >routes. > > >This would help simplify receiver side implementation wrt GR and >Enhanced RR. :) > >Regards, >Keyur > >On 1/28/14 1:08 PM, "Keyur Patel (keyupate)" wrote: > >>Sure! I am saying you can simplify the implementation by simply >>delaying the servicing of the route refresh reply till the generation >>of an EOR. >> >>Question is do we allow the text to be flexible enough to cover the >>other case. :) >> >>Regards, >>Keyur >> >>On 1/28/14 12:56 PM, "Jakob Heitz" wrote: >> >>>Could we please simplify this a bit, not to force implementations to >>>use different stale bits? >>> >>>Thanks, >>>Jakob. >>> >>>-----Original Message----- >>>From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] >>>Sent: Tuesday, January 28, 2014 12:49 PM >>>To: Jakob Heitz; Thomas Mangin; idr-bounces@ietf.org >>>Cc: idr@ietf.org >>>Subject: Re: [Idr] WG LC for >>>draft-ietf-idr-bgp-enhanced-route-refresh >>> >>> >>> >>>On 1/28/14 12:23 PM, "Jakob Heitz" wrote: >>> >>>>the order BoRR, EoR, EoRR allows this possible scenario: >>>> >>>>Suppose 2 routes exist :1.1.1.1/32, 2.2.2.2/32 The order could now be: >>>>. start session >>>>. send 1.1.1.1/32 >>>>. receive route refresh request. >>>>. send BoRR >>>>. send 2.2.2.2/32 >>>>. send EoR >>>>. send 1.1.1.1/32 >>>>. send EoRR >>>> >>>>On receipt of EoR, the receiver could delete stales, deleting >>>>1.1.1.1/32. >>> >>>Not if you use different flags/bits to mark them stale? >>> >>>Implementations could choose to always postpone the route refresh >>>reply and get the same behavior? >>> >>>Regards, >>>Keyur >>> >>>> >>>>Thanks, >>>>Jakob. >>>> >>>>-----Original Message----- >>>>From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] >>>>Sent: Tuesday, January 28, 2014 12:17 PM >>>>To: Jakob Heitz; Thomas Mangin; idr-bounces@ietf.org >>>>Cc: idr@ietf.org >>>>Subject: Re: [Idr] WG LC for >>>>draft-ietf-idr-bgp-enhanced-route-refresh >>>> >>>>The order: BoRR, EoR, EoRR lets an implementation do both, merge >>>>route refresh reply with an initial table announcement or delay the >>>>route refresh replies. As long as EoR is sent before EoRR there >>>>should be no issue right? >>>> >>>>Regards, >>>>Keyur >>>>On 1/28/14 12:06 PM, "Jakob Heitz" wrote: >>>> >>>>>Enke's text allows the order: BoRR, EoR, EoRR. >>>>> >>>>>Could we change Enke's text from >>>>>"it MUST NOT send an EoRR" to >>>>>"it MUST NOT send an BoRR" >>>>> >>>>>Thanks, >>>>>Jakob. >>>>> >>>>>-----Original Message----- >>>>>From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Keyur Patel >>>>>(keyupate) >>>>>Sent: Tuesday, January 28, 2014 11:51 AM >>>>>To: Thomas Mangin; idr-bounces@ietf.org >>>>>Cc: idr@ietf.org >>>>>Subject: Re: [Idr] WG LC for >>>>>draft-ietf-idr-bgp-enhanced-route-refresh >>>>> >>>>>Hi Jacob, Thomas, >>>>> >>>>>Am ok with implementations delaying the servicing of route refresh >>>>>request. Enke's suggested text addresses the concern. >>>>> >>>>>Best Regards, >>>>>Keyur >>>>> >>>>>On 1/26/14 3:39 PM, "Thomas Mangin" >>>>> >>>>>wrote: >>>>> >>>>>>Damn, time to practice then :) >>>>>> >>>>>>Joke apart, I agree with this post. The feature should not be used >>>>>>( and ignored ) until the initial route exchange has been completed. >>>>>> >>>>>>If the session drops, I would expect the router to cancel any RR >>>>>>which was ongoing as the AdjRIBOut is going to be retransmitted >>>>>>anyway. >>>>>> >>>>>>Thomas >>>>>> >>>>>>Sent from my iPad >>>>>> >>>>>>> On 25 Jan 2014, at 19:48, Jakob Heitz >>>>>>>wrote: >>>>>>> >>>>>>> RFCs are written for coders "practiced" in the art". >>>>>>> If anyone sends an EoRR before the adj-RIB-out is fully >>>>>>>populated, then it's a BUG. >>>>>>> This does not need to be said. >>>>>>> >>>>>>> Personally, I believe a route refresh request should not be >>>>>>>honored until GR is complete. >>>>>>> Also, I don't believe a timer for the receipt of EoRR is >>>>>>>necessary, because the EoRR is guaranteed. >>>>>>> Guaranteed means "unless the session drops first". >>>>>>> -- >>>>>>> >>>>>>> Jakob Heitz. >>>>>>> >>>>>>> ________________________________________ >>>>>>> From: Chris Hall [chris.hall@highwayman.com] >>>>>>> Sent: Saturday, 25 January 2014 11:27 AM >>>>>>> To: idr@ietf.org >>>>>>> Cc: Jakob Heitz >>>>>>> Subject: RE: [Idr] WG LC for >>>>>>> draft-ietf-idr-bgp-enhanced-route-refresh >>>>>>> >>>>>>> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): >>>>>>> ... >>>>>>>> Silence means don't do it. >>>>>>> >>>>>>> Hmmm.... as a principle I'm more comfortable with "that which >>>>>>> isn't prohibited is permitted".... >>>>>>> >>>>>>>> You would definitely NOT want BoRR to flush old stales. >>>>>>> >>>>>>> ....but, given the definite requirement, and given that the >>>>>>> current precedent for "marking stale" does flush old stale, then >>>>>>> a few words for the avoidance of doubt ? >>>>>>> >>>>>>>> Restarting the timer might be a good idea. >>>>>>> >>>>>>> I dunno... a route which remains stale for "a long time" is, of >>>>>>> course, a candidate for being withdrawn: so having started a >>>>>>> timer the first time things are set stale, I would avoid >>>>>>> extending that >>>>>>> -- at least for Graceful Restart, where the whole withdraw thing >>>>>>> has been "on-hold" since the last session failed. For >>>>>>> route-refresh I guess there's more of a presumption that stale >>>>>>> routes will be refreshed sooner or later, and in the meantime >>>>>>> they remain good. So if the route-refresh is (repeatedly) >>>>>>> restarted for some reason, perhaps it is more reasonable to >>>>>>> extend the flush deadline -- but avoid doing this indefinitely ? >>>>>>> >>>>>>> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I >>>>>>> have built in Quagga prioritise route changes (pending changes >>>>>>> and any that occur during the refresh) over refresh updates. >>>>>>> This makes it more likely that remaining stale routes are still good. >>>>>>> But the other end cannot know that. >>>>>>> >>>>>>> The paragraph in the draft discussing the "entire Adj-RIB-Out" >>>>>>> defines that to be the entries present "at the start of the >>>>>>>route refresh operation", and observes that these comprise both >>>>>>>reachable and unreachable routes. [An "of" after "comprise" sets >>>>>>>teeth on edge, BTW.] I'm really not sure what this paragraph is >>>>>>>trying to tell me. >>>>>>> The reference to unreachable routes appears to suggest that >>>>>>>pending withdraws should be sent as part of the refresh -- so not >>>>>>>left to the EoRR to implement at the end. The point at which the >>>>>>>EoRR is sent is defined such that it excludes any Adj-RIB-Out >>>>>>>entries added after the route-refresh started, but includes any >>>>>>>which are changed during the process. It seems reasonable to >>>>>>>delay any brand new reachable prefixes until after all previously >>>>>>>announced ones have been refreshed and the EoRR sent -- if that's >>>>>>>the intent here. >>>>>>>Changes which occur before the refresh gets to a given entry are >>>>>>>pretty naturally swept up by the refresh. Changes which occur >>>>>>>after the refresh has gone past, could/should be deferred to >>>>>>>after the EoRR ? >>>>>>> Does it make a difference if the change is a withdraw ? (Of >>>>>>>course MRAI may kick in here. Ah. MRAI and route-refresh, >>>>>>>there's a topic >>>>>>> !) >>>>>>> >>>>>>> I think the essence of the rule is that the EoRR should be sent >>>>>>>once all prefixes previously advertised to the peer as reachable >>>>>>>have been refreshed, ie announced or withdrawn (at least) once. >>>>>>>Or, perhaps more strictly, not *before* those prefixes have >>>>>>>*all* been announced once -- given that the EoRR will promptly >>>>>>>bang un-advertised stuff on the head. Even more strictly >>>>>>>perhaps: not send EoRR *before* any withdraws implied by it are >>>>>>>required or desirable. >>>>>>> >>>>>>> Depending on the implementation, a given sender may or may not >>>>>>>be able to determine the minimum set of updates required before >>>>>>>sending EoRR. >>>>>>> >>>>>>> If the refresh operation takes a long time, there may be good >>>>>>> routeing reasons to arrange for some route changes to be sent to >>>>>>> the peer "early" -- that is to send announcements which do not >>>>>>> contribute to the refresh, but which are important enough to >>>>>>> warrant delaying the end of the refresh. That could be a matter >>>>>>> for >>>>>>> recommendation(s) in the standard. >>>>>>> >>>>>>> NB: given that the timing of the EoRR is tied to the state of >>>>>>> the Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. >>>>>>> At the beginning of the initial update, the Restarting and >>>>>>> Receiving speakers have: >>>>>>> >>>>>>> Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out >>>>>>> >>>>>>> Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In >>>>>>> >>>>>>> Now suppose (bonkers or otherwise) the receiving speaker sends >>>>>>> an RRQ part way through the initial update. The restarting >>>>>>> speaker responds with BoRR, everything in its Adj-RIB-Out, and >>>>>>> EoRR -- per specification. The receiving speaker sees the EoRR, >>>>>>> and flushes stale. Unfortunately, if the restarting speaker has >>>>>>> not yet fully populated its Adj-RIB-Out, then many further >>>>>>> routes will be sent before the EoR falls due -- but the >>>>>>> receiving speaker has already flushed their tiny posteriors :-( >>>>>>> >>>>>>> I am coming to the view that route-refresh during a Graceful >>>>>>> Restart initial update is a horse of a different colour altogether. >>>>>>> >>>>>>> [So the assumption that EoRR and EoR are triggered by the same >>>>>>> thing was completely wrong, and I apologise for it.] >>>>>>> >>>>>>> Chris >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 > >_______________________________________________ >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 thomas.mangin@exa-networks.co.uk Tue Jan 28 23:45:09 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12F591A0420; Tue, 28 Jan 2014 23:45:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GzAvEOH7p8sX; Tue, 28 Jan 2014 23:45:05 -0800 (PST) Received: from out-7.mail.exa.net.uk (out-7.mail.exa.net.uk [82.219.4.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2178A1A03ED; Tue, 28 Jan 2014 23:45:04 -0800 (PST) Received: from smtp-4.mail.exa.net.uk (smtp-4.mail.exa.net.uk [82.219.5.4]) by out-7.mail.exa.net.uk (ExaSMTPD) with ESMTP id 2FEB3A0053; Wed, 29 Jan 2014 07:45:01 +0000 (GMT) Received: from [82.219.212.37] (ptr-37.212.219.82.rev.exa.net.uk [82.219.212.37]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: thomas@mangin.com) by smtp-4.mail.exa.net.uk (ExaSMTPD) with ESMTPSA id D983D4006B; Wed, 29 Jan 2014 07:45:00 +0000 (GMT) References: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F6E528@eusaamb109.ericsson.se> Mime-Version: 1.0 (1.0) In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F6E528@eusaamb109.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <1752130A-0D12-4129-A498-119B6E6D7A4B@exa-networks.co.uk> X-Mailer: iPad Mail (11B554a) From: Thomas Mangin Date: Wed, 29 Jan 2014 07:45:00 +0000 To: "jakob.heitz@ericsson.com" X-Virus-Scanned: clamav-milter 0.97.8 at out-2-2.mail.exa.net.uk X-Virus-Status: Clean Cc: "Keyur Patel \(keyupate\)" , "idr@ietf.org" , "idr-bounces@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 07:45:09 -0000 +1 too Sent from my iPad > On 28 Jan 2014, at 22:53, Jakob Heitz wrote: >=20 > Sold. >=20 > Thanks, > Jakob. >=20 > -----Original Message----- > From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com]=20 > Sent: Tuesday, January 28, 2014 1:43 PM > To: Keyur Patel (keyupate); Jakob Heitz; Thomas Mangin; idr-bounces@ietf.o= rg > Cc: idr@ietf.org > Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh >=20 > Hi Jakob,=20 >=20 > How about the following (based on your suggestion): >=20 > For a BGP speaker that supports the BGP Graceful Restart specified in [RFC= 4724] , it MUST NOT send a BoRR for an AFI/SAFI to a neighbor before it send= s the EOR for the AFI/SAFI to the neighbor. This procedure would help the n= eighbor avoid the premature cleanup of stale routes. >=20 >=20 > This would help simplify receiver side implementation wrt GR and Enhanced R= R. :) >=20 > Regards, > Keyur >=20 >> On 1/28/14 1:08 PM, "Keyur Patel (keyupate)" wrote: >>=20 >> Sure! I am saying you can simplify the implementation by simply=20 >> delaying the servicing of the route refresh reply till the generation of a= n EOR. >>=20 >> Question is do we allow the text to be flexible enough to cover the=20 >> other case. :) >>=20 >> Regards, >> Keyur >>=20 >>> On 1/28/14 12:56 PM, "Jakob Heitz" wrote: >>>=20 >>> Could we please simplify this a bit, not to force implementations to=20 >>> use different stale bits? >>>=20 >>> Thanks, >>> Jakob. >>>=20 >>> -----Original Message----- >>> From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] >>> Sent: Tuesday, January 28, 2014 12:49 PM >>> To: Jakob Heitz; Thomas Mangin; idr-bounces@ietf.org >>> Cc: idr@ietf.org >>> Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh >>>=20 >>>=20 >>>=20 >>>> On 1/28/14 12:23 PM, "Jakob Heitz" wrote: >>>>=20 >>>> the order BoRR, EoR, EoRR allows this possible scenario: >>>>=20 >>>> Suppose 2 routes exist :1.1.1.1/32, 2.2.2.2/32 The order could now be: >>>> . start session >>>> . send 1.1.1.1/32 >>>> . receive route refresh request. >>>> . send BoRR >>>> . send 2.2.2.2/32 >>>> . send EoR >>>> . send 1.1.1.1/32 >>>> . send EoRR >>>>=20 >>>> On receipt of EoR, the receiver could delete stales, deleting=20 >>>> 1.1.1.1/32. >>>=20 >>> Not if you use different flags/bits to mark them stale? >>>=20 >>> Implementations could choose to always postpone the route refresh=20 >>> reply and get the same behavior? >>>=20 >>> Regards, >>> Keyur >>>=20 >>>>=20 >>>> Thanks, >>>> Jakob. >>>>=20 >>>> -----Original Message----- >>>> From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] >>>> Sent: Tuesday, January 28, 2014 12:17 PM >>>> To: Jakob Heitz; Thomas Mangin; idr-bounces@ietf.org >>>> Cc: idr@ietf.org >>>> Subject: Re: [Idr] WG LC for=20 >>>> draft-ietf-idr-bgp-enhanced-route-refresh >>>>=20 >>>> The order: BoRR, EoR, EoRR lets an implementation do both, merge=20 >>>> route refresh reply with an initial table announcement or delay the=20 >>>> route refresh replies. As long as EoR is sent before EoRR there=20 >>>> should be no issue right? >>>>=20 >>>> Regards, >>>> Keyur >>>>> On 1/28/14 12:06 PM, "Jakob Heitz" wrote: >>>>>=20 >>>>> Enke's text allows the order: BoRR, EoR, EoRR. >>>>>=20 >>>>> Could we change Enke's text from >>>>> "it MUST NOT send an EoRR" to >>>>> "it MUST NOT send an BoRR" >>>>>=20 >>>>> Thanks, >>>>> Jakob. >>>>>=20 >>>>> -----Original Message----- >>>>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Keyur Patel >>>>> (keyupate) >>>>> Sent: Tuesday, January 28, 2014 11:51 AM >>>>> To: Thomas Mangin; idr-bounces@ietf.org >>>>> Cc: idr@ietf.org >>>>> Subject: Re: [Idr] WG LC for=20 >>>>> draft-ietf-idr-bgp-enhanced-route-refresh >>>>>=20 >>>>> Hi Jacob, Thomas, >>>>>=20 >>>>> Am ok with implementations delaying the servicing of route refresh=20 >>>>> request. Enke's suggested text addresses the concern. >>>>>=20 >>>>> Best Regards, >>>>> Keyur >>>>>=20 >>>>> On 1/26/14 3:39 PM, "Thomas Mangin"=20 >>>>> >>>>> wrote: >>>>>=20 >>>>>> Damn, time to practice then :) >>>>>>=20 >>>>>> Joke apart, I agree with this post. The feature should not be used=20= >>>>>> ( and ignored ) until the initial route exchange has been completed. >>>>>>=20 >>>>>> If the session drops, I would expect the router to cancel any RR=20 >>>>>> which was ongoing as the AdjRIBOut is going to be retransmitted=20 >>>>>> anyway. >>>>>>=20 >>>>>> Thomas >>>>>>=20 >>>>>> Sent from my iPad >>>>>>=20 >>>>>>> On 25 Jan 2014, at 19:48, Jakob Heitz >>>>>>> wrote: >>>>>>>=20 >>>>>>> RFCs are written for coders "practiced" in the art". >>>>>>> If anyone sends an EoRR before the adj-RIB-out is fully=20 >>>>>>> populated, then it's a BUG. >>>>>>> This does not need to be said. >>>>>>>=20 >>>>>>> Personally, I believe a route refresh request should not be=20 >>>>>>> honored until GR is complete. >>>>>>> Also, I don't believe a timer for the receipt of EoRR is=20 >>>>>>> necessary, because the EoRR is guaranteed. >>>>>>> Guaranteed means "unless the session drops first". >>>>>>> -- >>>>>>>=20 >>>>>>> Jakob Heitz. >>>>>>>=20 >>>>>>> ________________________________________ >>>>>>> From: Chris Hall [chris.hall@highwayman.com] >>>>>>> Sent: Saturday, 25 January 2014 11:27 AM >>>>>>> To: idr@ietf.org >>>>>>> Cc: Jakob Heitz >>>>>>> Subject: RE: [Idr] WG LC for >>>>>>> draft-ietf-idr-bgp-enhanced-route-refresh >>>>>>>=20 >>>>>>> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): >>>>>>> ... >>>>>>>> Silence means don't do it. >>>>>>>=20 >>>>>>> Hmmm.... as a principle I'm more comfortable with "that which=20 >>>>>>> isn't prohibited is permitted".... >>>>>>>=20 >>>>>>>> You would definitely NOT want BoRR to flush old stales. >>>>>>>=20 >>>>>>> ....but, given the definite requirement, and given that the=20 >>>>>>> current precedent for "marking stale" does flush old stale, then=20 >>>>>>> a few words for the avoidance of doubt ? >>>>>>>=20 >>>>>>>> Restarting the timer might be a good idea. >>>>>>>=20 >>>>>>> I dunno... a route which remains stale for "a long time" is, of=20 >>>>>>> course, a candidate for being withdrawn: so having started a=20 >>>>>>> timer the first time things are set stale, I would avoid=20 >>>>>>> extending that >>>>>>> -- at least for Graceful Restart, where the whole withdraw thing=20 >>>>>>> has been "on-hold" since the last session failed. For=20 >>>>>>> route-refresh I guess there's more of a presumption that stale=20 >>>>>>> routes will be refreshed sooner or later, and in the meantime=20 >>>>>>> they remain good. So if the route-refresh is (repeatedly)=20 >>>>>>> restarted for some reason, perhaps it is more reasonable to=20 >>>>>>> extend the flush deadline -- but avoid doing this indefinitely ? >>>>>>>=20 >>>>>>> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I=20 >>>>>>> have built in Quagga prioritise route changes (pending changes=20 >>>>>>> and any that occur during the refresh) over refresh updates. =20 >>>>>>> This makes it more likely that remaining stale routes are still good= . >>>>>>> But the other end cannot know that. >>>>>>>=20 >>>>>>> The paragraph in the draft discussing the "entire Adj-RIB-Out" >>>>>>> defines that to be the entries present "at the start of the route=20= >>>>>>> refresh operation", and observes that these comprise both=20 >>>>>>> reachable and unreachable routes. [An "of" after "comprise" sets=20= >>>>>>> teeth on edge, BTW.] I'm really not sure what this paragraph is=20 >>>>>>> trying to tell me. >>>>>>> The reference to unreachable routes appears to suggest that=20 >>>>>>> pending withdraws should be sent as part of the refresh -- so not=20= >>>>>>> left to the EoRR to implement at the end. The point at which the=20= >>>>>>> EoRR is sent is defined such that it excludes any Adj-RIB-Out=20 >>>>>>> entries added after the route-refresh started, but includes any=20 >>>>>>> which are changed during the process. It seems reasonable to=20 >>>>>>> delay any brand new reachable prefixes until after all previously=20= >>>>>>> announced ones have been refreshed and the EoRR sent -- if that's th= e intent here. >>>>>>> Changes which occur before the refresh gets to a given entry are=20 >>>>>>> pretty naturally swept up by the refresh. Changes which occur=20 >>>>>>> after the refresh has gone past, could/should be deferred to after=20= >>>>>>> the EoRR ? >>>>>>> Does it make a difference if the change is a withdraw ? (Of=20 >>>>>>> course MRAI may kick in here. Ah. MRAI and route-refresh,=20 >>>>>>> there's a topic >>>>>>> !) >>>>>>>=20 >>>>>>> I think the essence of the rule is that the EoRR should be sent=20 >>>>>>> once all prefixes previously advertised to the peer as reachable=20= >>>>>>> have been refreshed, ie announced or withdrawn (at least) once. >>>>>>> Or, perhaps more strictly, not *before* those prefixes have *all*=20= >>>>>>> been announced once -- given that the EoRR will promptly bang=20 >>>>>>> un-advertised stuff on the head. Even more strictly perhaps: not=20= >>>>>>> send EoRR *before* any withdraws implied by it are required or=20 >>>>>>> desirable. >>>>>>>=20 >>>>>>> Depending on the implementation, a given sender may or may not be=20= >>>>>>> able to determine the minimum set of updates required before=20 >>>>>>> sending EoRR. >>>>>>>=20 >>>>>>> If the refresh operation takes a long time, there may be good=20 >>>>>>> routeing reasons to arrange for some route changes to be sent to=20 >>>>>>> the peer "early" -- that is to send announcements which do not=20 >>>>>>> contribute to the refresh, but which are important enough to=20 >>>>>>> warrant delaying the end of the refresh. That could be a matter=20 >>>>>>> for >>>>>>> recommendation(s) in the standard. >>>>>>>=20 >>>>>>> NB: given that the timing of the EoRR is tied to the state of the=20= >>>>>>> Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. >>>>>>> At the beginning of the initial update, the Restarting and=20 >>>>>>> Receiving speakers have: >>>>>>>=20 >>>>>>> Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out >>>>>>>=20 >>>>>>> Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In >>>>>>>=20 >>>>>>> Now suppose (bonkers or otherwise) the receiving speaker sends an=20= >>>>>>> RRQ part way through the initial update. The restarting speaker=20 >>>>>>> responds with BoRR, everything in its Adj-RIB-Out, and EoRR --=20 >>>>>>> per specification. The receiving speaker sees the EoRR, and=20 >>>>>>> flushes stale. Unfortunately, if the restarting speaker has not=20 >>>>>>> yet fully populated its Adj-RIB-Out, then many further routes=20 >>>>>>> will be sent before the EoR falls due -- but the receiving=20 >>>>>>> speaker has already flushed their tiny posteriors :-( >>>>>>>=20 >>>>>>> I am coming to the view that route-refresh during a Graceful=20 >>>>>>> Restart initial update is a horse of a different colour altogether. >>>>>>>=20 >>>>>>> [So the assumption that EoRR and EoR are triggered by the same=20 >>>>>>> thing was completely wrong, and I apologise for it.] >>>>>>>=20 >>>>>>> Chris >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>=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 >=20 From thomas.mangin@exa-networks.co.uk Tue Jan 28 23:50:37 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 577491A03ED; Tue, 28 Jan 2014 23:50:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TB9MdBY3TOGA; Tue, 28 Jan 2014 23:50:34 -0800 (PST) Received: from out-7.mail.exa.net.uk (out-7.mail.exa.net.uk [82.219.4.135]) by ietfa.amsl.com (Postfix) with ESMTP id BB1CA1A0453; Tue, 28 Jan 2014 23:50:31 -0800 (PST) Received: from smtp-3.mail.exa.net.uk (smtp-1.mail.exa.net.uk [82.219.5.1]) by out-7.mail.exa.net.uk (ExaSMTPD) with ESMTP id 559EEA0056; Wed, 29 Jan 2014 07:50:28 +0000 (GMT) Received: from [82.219.212.37] (ptr-37.212.219.82.rev.exa.net.uk [82.219.212.37]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: thomas@mangin.com) by smtp-3.mail.exa.net.uk (ExaSMTPD) with ESMTPSA id 1830B22115D; Wed, 29 Jan 2014 07:50:28 +0000 (GMT) References: <010801cf1c8c$6b1a0420$414e0c60$@ndzh.com> <8ED5B0B0F5B4854A912480C1521F973A11AFBD56@xmb-rcd-x13.cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <8ED5B0B0F5B4854A912480C1521F973A11AFBD56@xmb-rcd-x13.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <6D84FB20-2A48-4830-92F5-C81C5F4AA36A@exa-networks.co.uk> X-Mailer: iPad Mail (11B554a) From: Thomas Mangin Date: Wed, 29 Jan 2014 07:50:27 +0000 To: "sairay@cisco.com" X-Virus-Scanned: clamav-milter 0.97.8 at out-2-2.mail.exa.net.uk X-Virus-Status: Clean Cc: "idr@ietf.org" , "Keyur Patel \(keyupate\)" , "idr-bounces@ietf.org" , Susan Hares Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 07:50:37 -0000 Hello Saikat, Why "both by the sender", if the route was not announced it is clearly withd= rawn on the sender side and by definition if a route is not in the RR it has= to be withdrawn - that said saying it can not harm .. Thomas Sent from my iPad > On 29 Jan 2014, at 01:03, "Saikat Ray \(sairay\)" wrote= : >=20 > The draft should add a line mandating the actual semantics (instead of/in a= ddition to the procedures of mark-and-sweep). Something along the line:=20 >=20 > "Any route for which no update has been sent between a BoRR and the follow= ing EoRR MUST be considered withdrawn by both the sender and the receiver." >=20 > The rest is really implementation (how to handle nested BoRR/EoRR or GR Eo= R, etc.), IMHO. >=20 > I support the draft, BTW. >=20 > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares > Sent: Tuesday, January 28, 2014 4:53 PM > To: 'Jeff Tantsura'; Keyur Patel (keyupate); 'Jakob Heitz'; 'Thomas Mangin= '; idr-bounces@ietf.org > Cc: idr@ietf.org > Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh >=20 > Any other comments? (support/discussion accepted) >=20 > Sue Hares >=20 > PS - Keyur - spin a draft with this change and end it to me.=20 >=20 > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jeff Tantsura > Sent: Tuesday, January 28, 2014 5:56 PM > To: Keyur Patel (keyupate); Jakob Heitz; Thomas Mangin; idr-bounces@ietf.o= rg > Cc: idr@ietf.org > Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh >=20 > I support the wording below. >=20 > Cheers, > Jeff >=20 >=20 > -----Original Message----- > From: "keyupate@cisco.com" > Date: Tuesday, January 28, 2014 1:43 PM > To: "keyupate@cisco.com" , Jakob Heitz , Thomas Mangin , "idr-bounces@= ietf.org" > > Cc: "idr@ietf.org" > Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh >=20 >> Hi Jakob, >>=20 >> How about the following (based on your suggestion): >>=20 >> For a BGP speaker that supports the BGP Graceful Restart specified in=20 >> [RFC4724] , it MUST NOT send a BoRR for an AFI/SAFI to a neighbor=20 >> before it sends the EOR for the AFI/SAFI to the neighbor. This=20 >> procedure would help the neighbor avoid the premature cleanup of stale=20= >> routes. >>=20 >>=20 >> This would help simplify receiver side implementation wrt GR and=20 >> Enhanced RR. :) >>=20 >> Regards, >> Keyur >>=20 >>> On 1/28/14 1:08 PM, "Keyur Patel (keyupate)" wrote:= >>>=20 >>> Sure! I am saying you can simplify the implementation by simply=20 >>> delaying the servicing of the route refresh reply till the generation=20= >>> of > an EOR. >>>=20 >>> Question is do we allow the text to be flexible enough to cover the=20 >>> other case. :) >>>=20 >>> Regards, >>> Keyur >>>=20 >>>> On 1/28/14 12:56 PM, "Jakob Heitz" wrote: >>>>=20 >>>> Could we please simplify this a bit, not to force implementations to=20= >>>> use different stale bits? >>>>=20 >>>> Thanks, >>>> Jakob. >>>>=20 >>>> -----Original Message----- >>>> From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] >>>> Sent: Tuesday, January 28, 2014 12:49 PM >>>> To: Jakob Heitz; Thomas Mangin; idr-bounces@ietf.org >>>> Cc: idr@ietf.org >>>> Subject: Re: [Idr] WG LC for >>>> draft-ietf-idr-bgp-enhanced-route-refresh >>>>=20 >>>>=20 >>>>=20 >>>>> On 1/28/14 12:23 PM, "Jakob Heitz" wrote: >>>>>=20 >>>>> the order BoRR, EoR, EoRR allows this possible scenario: >>>>>=20 >>>>> Suppose 2 routes exist :1.1.1.1/32, 2.2.2.2/32 The order could now be:= >>>>> . start session >>>>> . send 1.1.1.1/32 >>>>> . receive route refresh request. >>>>> . send BoRR >>>>> . send 2.2.2.2/32 >>>>> . send EoR >>>>> . send 1.1.1.1/32 >>>>> . send EoRR >>>>>=20 >>>>> On receipt of EoR, the receiver could delete stales, deleting=20 >>>>> 1.1.1.1/32. >>>>=20 >>>> Not if you use different flags/bits to mark them stale? >>>>=20 >>>> Implementations could choose to always postpone the route refresh=20 >>>> reply and get the same behavior? >>>>=20 >>>> Regards, >>>> Keyur >>>>=20 >>>>>=20 >>>>> Thanks, >>>>> Jakob. >>>>>=20 >>>>> -----Original Message----- >>>>> From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] >>>>> Sent: Tuesday, January 28, 2014 12:17 PM >>>>> To: Jakob Heitz; Thomas Mangin; idr-bounces@ietf.org >>>>> Cc: idr@ietf.org >>>>> Subject: Re: [Idr] WG LC for >>>>> draft-ietf-idr-bgp-enhanced-route-refresh >>>>>=20 >>>>> The order: BoRR, EoR, EoRR lets an implementation do both, merge=20 >>>>> route refresh reply with an initial table announcement or delay the=20= >>>>> route refresh replies. As long as EoR is sent before EoRR there=20 >>>>> should be no issue right? >>>>>=20 >>>>> Regards, >>>>> Keyur >>>>>> On 1/28/14 12:06 PM, "Jakob Heitz" wrote: >>>>>>=20 >>>>>> Enke's text allows the order: BoRR, EoR, EoRR. >>>>>>=20 >>>>>> Could we change Enke's text from >>>>>> "it MUST NOT send an EoRR" to >>>>>> "it MUST NOT send an BoRR" >>>>>>=20 >>>>>> Thanks, >>>>>> Jakob. >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Keyur Patel >>>>>> (keyupate) >>>>>> Sent: Tuesday, January 28, 2014 11:51 AM >>>>>> To: Thomas Mangin; idr-bounces@ietf.org >>>>>> Cc: idr@ietf.org >>>>>> Subject: Re: [Idr] WG LC for >>>>>> draft-ietf-idr-bgp-enhanced-route-refresh >>>>>>=20 >>>>>> Hi Jacob, Thomas, >>>>>>=20 >>>>>> Am ok with implementations delaying the servicing of route refresh=20= >>>>>> request. Enke's suggested text addresses the concern. >>>>>>=20 >>>>>> Best Regards, >>>>>> Keyur >>>>>>=20 >>>>>> On 1/26/14 3:39 PM, "Thomas Mangin"=20 >>>>>> >>>>>> wrote: >>>>>>=20 >>>>>>> Damn, time to practice then :) >>>>>>>=20 >>>>>>> Joke apart, I agree with this post. The feature should not be used=20= >>>>>>> ( and ignored ) until the initial route exchange has been completed.= >>>>>>>=20 >>>>>>> If the session drops, I would expect the router to cancel any RR=20 >>>>>>> which was ongoing as the AdjRIBOut is going to be retransmitted=20 >>>>>>> anyway. >>>>>>>=20 >>>>>>> Thomas >>>>>>>=20 >>>>>>> Sent from my iPad >>>>>>>=20 >>>>>>>> On 25 Jan 2014, at 19:48, Jakob Heitz >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>> RFCs are written for coders "practiced" in the art". >>>>>>>> If anyone sends an EoRR before the adj-RIB-out is fully=20 >>>>>>>> populated, then it's a BUG. >>>>>>>> This does not need to be said. >>>>>>>>=20 >>>>>>>> Personally, I believe a route refresh request should not be=20 >>>>>>>> honored until GR is complete. >>>>>>>> Also, I don't believe a timer for the receipt of EoRR is=20 >>>>>>>> necessary, because the EoRR is guaranteed. >>>>>>>> Guaranteed means "unless the session drops first". >>>>>>>> -- >>>>>>>>=20 >>>>>>>> Jakob Heitz. >>>>>>>>=20 >>>>>>>> ________________________________________ >>>>>>>> From: Chris Hall [chris.hall@highwayman.com] >>>>>>>> Sent: Saturday, 25 January 2014 11:27 AM >>>>>>>> To: idr@ietf.org >>>>>>>> Cc: Jakob Heitz >>>>>>>> Subject: RE: [Idr] WG LC for >>>>>>>> draft-ietf-idr-bgp-enhanced-route-refresh >>>>>>>>=20 >>>>>>>> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): >>>>>>>> ... >>>>>>>>> Silence means don't do it. >>>>>>>>=20 >>>>>>>> Hmmm.... as a principle I'm more comfortable with "that which=20 >>>>>>>> isn't prohibited is permitted".... >>>>>>>>=20 >>>>>>>>> You would definitely NOT want BoRR to flush old stales. >>>>>>>>=20 >>>>>>>> ....but, given the definite requirement, and given that the=20 >>>>>>>> current precedent for "marking stale" does flush old stale, then=20= >>>>>>>> a few words for the avoidance of doubt ? >>>>>>>>=20 >>>>>>>>> Restarting the timer might be a good idea. >>>>>>>>=20 >>>>>>>> I dunno... a route which remains stale for "a long time" is, of=20 >>>>>>>> course, a candidate for being withdrawn: so having started a=20 >>>>>>>> timer the first time things are set stale, I would avoid=20 >>>>>>>> extending that >>>>>>>> -- at least for Graceful Restart, where the whole withdraw thing=20= >>>>>>>> has been "on-hold" since the last session failed. For=20 >>>>>>>> route-refresh I guess there's more of a presumption that stale=20 >>>>>>>> routes will be refreshed sooner or later, and in the meantime=20 >>>>>>>> they remain good. So if the route-refresh is (repeatedly)=20 >>>>>>>> restarted for some reason, perhaps it is more reasonable to=20 >>>>>>>> extend the flush deadline -- but avoid doing this indefinitely ? >>>>>>>>=20 >>>>>>>> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I=20 >>>>>>>> have built in Quagga prioritise route changes (pending changes=20 >>>>>>>> and any that occur during the refresh) over refresh updates. >>>>>>>> This makes it more likely that remaining stale routes are still > good. >>>>>>>> But the other end cannot know that. >>>>>>>>=20 >>>>>>>> The paragraph in the draft discussing the "entire Adj-RIB-Out" >>>>>>>> defines that to be the entries present "at the start of the=20 >>>>>>>> route refresh operation", and observes that these comprise both=20 >>>>>>>> reachable and unreachable routes. [An "of" after "comprise" sets=20= >>>>>>>> teeth on edge, BTW.] I'm really not sure what this paragraph is=20= >>>>>>>> trying to tell me. >>>>>>>> The reference to unreachable routes appears to suggest that=20 >>>>>>>> pending withdraws should be sent as part of the refresh -- so not=20= >>>>>>>> left to the EoRR to implement at the end. The point at which the=20= >>>>>>>> EoRR is sent is defined such that it excludes any Adj-RIB-Out=20 >>>>>>>> entries added after the route-refresh started, but includes any=20 >>>>>>>> which are changed during the process. It seems reasonable to=20 >>>>>>>> delay any brand new reachable prefixes until after all previously=20= >>>>>>>> announced ones have been refreshed and the EoRR sent -- if that's=20= >>>>>>>> the > intent here. >>>>>>>> Changes which occur before the refresh gets to a given entry are=20= >>>>>>>> pretty naturally swept up by the refresh. Changes which occur=20 >>>>>>>> after the refresh has gone past, could/should be deferred to=20 >>>>>>>> after the EoRR ? >>>>>>>> Does it make a difference if the change is a withdraw ? (Of=20 >>>>>>>> course MRAI may kick in here. Ah. MRAI and route-refresh,=20 >>>>>>>> there's a topic >>>>>>>> !) >>>>>>>>=20 >>>>>>>> I think the essence of the rule is that the EoRR should be sent=20 >>>>>>>> once all prefixes previously advertised to the peer as reachable=20= >>>>>>>> have been refreshed, ie announced or withdrawn (at least) once. >>>>>>>> Or, perhaps more strictly, not *before* those prefixes have >>>>>>>> *all* been announced once -- given that the EoRR will promptly=20 >>>>>>>> bang un-advertised stuff on the head. Even more strictly >>>>>>>> perhaps: not send EoRR *before* any withdraws implied by it are=20 >>>>>>>> required or desirable. >>>>>>>>=20 >>>>>>>> Depending on the implementation, a given sender may or may not=20 >>>>>>>> be able to determine the minimum set of updates required before=20 >>>>>>>> sending EoRR. >>>>>>>>=20 >>>>>>>> If the refresh operation takes a long time, there may be good=20 >>>>>>>> routeing reasons to arrange for some route changes to be sent to=20= >>>>>>>> the peer "early" -- that is to send announcements which do not=20 >>>>>>>> contribute to the refresh, but which are important enough to=20 >>>>>>>> warrant delaying the end of the refresh. That could be a matter=20= >>>>>>>> for >>>>>>>> recommendation(s) in the standard. >>>>>>>>=20 >>>>>>>> NB: given that the timing of the EoRR is tied to the state of=20 >>>>>>>> the Adj-RIB-Out, I'm not sure about the Graceful Restart > assumptions. >>>>>>>> At the beginning of the initial update, the Restarting and=20 >>>>>>>> Receiving speakers have: >>>>>>>>=20 >>>>>>>> Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out >>>>>>>>=20 >>>>>>>> Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In >>>>>>>>=20 >>>>>>>> Now suppose (bonkers or otherwise) the receiving speaker sends=20 >>>>>>>> an RRQ part way through the initial update. The restarting=20 >>>>>>>> speaker responds with BoRR, everything in its Adj-RIB-Out, and=20 >>>>>>>> EoRR -- per specification. The receiving speaker sees the EoRR,=20= >>>>>>>> and flushes stale. Unfortunately, if the restarting speaker has=20= >>>>>>>> not yet fully populated its Adj-RIB-Out, then many further=20 >>>>>>>> routes will be sent before the EoR falls due -- but the=20 >>>>>>>> receiving speaker has already flushed their tiny posteriors :-( >>>>>>>>=20 >>>>>>>> I am coming to the view that route-refresh during a Graceful=20 >>>>>>>> Restart initial update is a horse of a different colour altogether.= >>>>>>>>=20 >>>>>>>> [So the assumption that EoRR and EoR are triggered by the same=20 >>>>>>>> thing was completely wrong, and I apologise for it.] >>>>>>>>=20 >>>>>>>> Chris >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>>=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 >=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 From jie.dong@huawei.com Wed Jan 29 00:02:32 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64071A03DA; Wed, 29 Jan 2014 00:02:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HocnwFlsz7PF; Wed, 29 Jan 2014 00:02:28 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 646591A02A6; Wed, 29 Jan 2014 00:02:27 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDA91422; Wed, 29 Jan 2014 08:02:22 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 29 Jan 2014 08:01:59 +0000 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 29 Jan 2014 08:02:18 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.51]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Wed, 29 Jan 2014 16:02:13 +0800 From: "Dongjie (Jimmy)" To: "Keyur Patel (keyupate)" , Jakob Heitz , Thomas Mangin , "idr-bounces@ietf.org" Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPF5KdKHMolEg8TF26AxOKep0T6JqRMOhAgADFQgCAAAwAgIAAC4YAgAARhoCAABvfAIAABfyAgAAe94CAABsuAIABU5kAgAAED4CAAX72AIAABbyAgAHS7ACAAuS2AIAABIQAgAAC0YCAAAG5gIAAB0oAgAACCYCAAAM5gIAACceAgAEwz4A= Date: Wed, 29 Jan 2014 08:02:12 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927335C6AFB@nkgeml512-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.194.62] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 08:02:33 -0000 Support the new text. Best regards, Jie -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Keyur Patel (keyupate) Sent: Wednesday, January 29, 2014 12:43 AM To: Keyur Patel (keyupate); Jakob Heitz; Thomas Mangin; idr-bounces@ietf.or= g Cc: idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Jakob,=20 How about the following (based on your suggestion): For a BGP speaker that supports the BGP Graceful Restart specified in [RFC4= 724] , it MUST NOT send a BoRR for an AFI/SAFI to a neighbor before it send= s the EOR for the AFI/SAFI to the neighbor. This procedure would help the = neighbor avoid the premature cleanup of stale routes. This would help simplify receiver side implementation wrt GR and Enhanced R= R. :) Regards, Keyur On 1/28/14 1:08 PM, "Keyur Patel (keyupate)" wrote: >Sure! I am saying you can simplify the implementation by simply=20 >delaying the servicing of the route refresh reply till the generation of a= n EOR. > >Question is do we allow the text to be flexible enough to cover the=20 >other case. :) > >Regards, >Keyur > >On 1/28/14 12:56 PM, "Jakob Heitz" wrote: > >>Could we please simplify this a bit, not to force implementations to=20 >>use different stale bits? >> >>Thanks, >>Jakob. >> >>-----Original Message----- >>From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] >>Sent: Tuesday, January 28, 2014 12:49 PM >>To: Jakob Heitz; Thomas Mangin; idr-bounces@ietf.org >>Cc: idr@ietf.org >>Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh >> >> >> >>On 1/28/14 12:23 PM, "Jakob Heitz" wrote: >> >>>the order BoRR, EoR, EoRR allows this possible scenario: >>> >>>Suppose 2 routes exist :1.1.1.1/32, 2.2.2.2/32 The order could now be: >>>. start session >>>. send 1.1.1.1/32 >>>. receive route refresh request. >>>. send BoRR >>>. send 2.2.2.2/32 >>>. send EoR >>>. send 1.1.1.1/32 >>>. send EoRR >>> >>>On receipt of EoR, the receiver could delete stales, deleting=20 >>>1.1.1.1/32. >> >>Not if you use different flags/bits to mark them stale? >> >>Implementations could choose to always postpone the route refresh=20 >>reply and get the same behavior? >> >>Regards, >>Keyur >> >>> >>>Thanks, >>>Jakob. >>> >>>-----Original Message----- >>>From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] >>>Sent: Tuesday, January 28, 2014 12:17 PM >>>To: Jakob Heitz; Thomas Mangin; idr-bounces@ietf.org >>>Cc: idr@ietf.org >>>Subject: Re: [Idr] WG LC for=20 >>>draft-ietf-idr-bgp-enhanced-route-refresh >>> >>>The order: BoRR, EoR, EoRR lets an implementation do both, merge=20 >>>route refresh reply with an initial table announcement or delay the=20 >>>route refresh replies. As long as EoR is sent before EoRR there=20 >>>should be no issue right? >>> >>>Regards, >>>Keyur >>>On 1/28/14 12:06 PM, "Jakob Heitz" wrote: >>> >>>>Enke's text allows the order: BoRR, EoR, EoRR. >>>> >>>>Could we change Enke's text from >>>>"it MUST NOT send an EoRR" to >>>>"it MUST NOT send an BoRR" >>>> >>>>Thanks, >>>>Jakob. >>>> >>>>-----Original Message----- >>>>From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Keyur Patel >>>>(keyupate) >>>>Sent: Tuesday, January 28, 2014 11:51 AM >>>>To: Thomas Mangin; idr-bounces@ietf.org >>>>Cc: idr@ietf.org >>>>Subject: Re: [Idr] WG LC for=20 >>>>draft-ietf-idr-bgp-enhanced-route-refresh >>>> >>>>Hi Jacob, Thomas, >>>> >>>>Am ok with implementations delaying the servicing of route refresh=20 >>>>request. Enke's suggested text addresses the concern. >>>> >>>>Best Regards, >>>>Keyur >>>> >>>>On 1/26/14 3:39 PM, "Thomas Mangin"=20 >>>> >>>>wrote: >>>> >>>>>Damn, time to practice then :) >>>>> >>>>>Joke apart, I agree with this post. The feature should not be used=20 >>>>>( and ignored ) until the initial route exchange has been completed. >>>>> >>>>>If the session drops, I would expect the router to cancel any RR=20 >>>>>which was ongoing as the AdjRIBOut is going to be retransmitted=20 >>>>>anyway. >>>>> >>>>>Thomas >>>>> >>>>>Sent from my iPad >>>>> >>>>>> On 25 Jan 2014, at 19:48, Jakob Heitz >>>>>>wrote: >>>>>>=20 >>>>>> RFCs are written for coders "practiced" in the art". >>>>>> If anyone sends an EoRR before the adj-RIB-out is fully=20 >>>>>>populated, then it's a BUG. >>>>>> This does not need to be said. >>>>>>=20 >>>>>> Personally, I believe a route refresh request should not be=20 >>>>>>honored until GR is complete. >>>>>> Also, I don't believe a timer for the receipt of EoRR is=20 >>>>>>necessary, because the EoRR is guaranteed. >>>>>> Guaranteed means "unless the session drops first". >>>>>> -- >>>>>>=20 >>>>>> Jakob Heitz. >>>>>>=20 >>>>>> ________________________________________ >>>>>> From: Chris Hall [chris.hall@highwayman.com] >>>>>> Sent: Saturday, 25 January 2014 11:27 AM >>>>>> To: idr@ietf.org >>>>>> Cc: Jakob Heitz >>>>>> Subject: RE: [Idr] WG LC for >>>>>> draft-ietf-idr-bgp-enhanced-route-refresh >>>>>>=20 >>>>>> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): >>>>>> ... >>>>>>> Silence means don't do it. >>>>>>=20 >>>>>> Hmmm.... as a principle I'm more comfortable with "that which=20 >>>>>> isn't prohibited is permitted".... >>>>>>=20 >>>>>>> You would definitely NOT want BoRR to flush old stales. >>>>>>=20 >>>>>> ....but, given the definite requirement, and given that the=20 >>>>>> current precedent for "marking stale" does flush old stale, then=20 >>>>>> a few words for the avoidance of doubt ? >>>>>>=20 >>>>>>> Restarting the timer might be a good idea. >>>>>>=20 >>>>>> I dunno... a route which remains stale for "a long time" is, of=20 >>>>>> course, a candidate for being withdrawn: so having started a=20 >>>>>> timer the first time things are set stale, I would avoid=20 >>>>>> extending that >>>>>> -- at least for Graceful Restart, where the whole withdraw thing=20 >>>>>> has been "on-hold" since the last session failed. For=20 >>>>>> route-refresh I guess there's more of a presumption that stale=20 >>>>>> routes will be refreshed sooner or later, and in the meantime=20 >>>>>> they remain good. So if the route-refresh is (repeatedly)=20 >>>>>> restarted for some reason, perhaps it is more reasonable to=20 >>>>>> extend the flush deadline -- but avoid doing this indefinitely ? >>>>>>=20 >>>>>> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I=20 >>>>>> have built in Quagga prioritise route changes (pending changes=20 >>>>>> and any that occur during the refresh) over refresh updates. =20 >>>>>> This makes it more likely that remaining stale routes are still good= . >>>>>> But the other end cannot know that. >>>>>>=20 >>>>>> The paragraph in the draft discussing the "entire Adj-RIB-Out" >>>>>> defines that to be the entries present "at the start of the route=20 >>>>>>refresh operation", and observes that these comprise both=20 >>>>>>reachable and unreachable routes. [An "of" after "comprise" sets=20 >>>>>>teeth on edge, BTW.] I'm really not sure what this paragraph is=20 >>>>>>trying to tell me. >>>>>> The reference to unreachable routes appears to suggest that=20 >>>>>>pending withdraws should be sent as part of the refresh -- so not=20 >>>>>>left to the EoRR to implement at the end. The point at which the=20 >>>>>>EoRR is sent is defined such that it excludes any Adj-RIB-Out=20 >>>>>>entries added after the route-refresh started, but includes any=20 >>>>>>which are changed during the process. It seems reasonable to=20 >>>>>>delay any brand new reachable prefixes until after all previously=20 >>>>>>announced ones have been refreshed and the EoRR sent -- if that's the= intent here. >>>>>>Changes which occur before the refresh gets to a given entry are=20 >>>>>>pretty naturally swept up by the refresh. Changes which occur=20 >>>>>>after the refresh has gone past, could/should be deferred to after=20 >>>>>>the EoRR ? >>>>>> Does it make a difference if the change is a withdraw ? (Of=20 >>>>>>course MRAI may kick in here. Ah. MRAI and route-refresh,=20 >>>>>>there's a topic >>>>>> !) >>>>>>=20 >>>>>> I think the essence of the rule is that the EoRR should be sent=20 >>>>>>once all prefixes previously advertised to the peer as reachable=20 >>>>>>have been refreshed, ie announced or withdrawn (at least) once. >>>>>>Or, perhaps more strictly, not *before* those prefixes have *all*=20 >>>>>>been announced once -- given that the EoRR will promptly bang=20 >>>>>>un-advertised stuff on the head. Even more strictly perhaps: not=20 >>>>>>send EoRR *before* any withdraws implied by it are required or=20 >>>>>>desirable. >>>>>>=20 >>>>>> Depending on the implementation, a given sender may or may not be=20 >>>>>>able to determine the minimum set of updates required before=20 >>>>>>sending EoRR. >>>>>>=20 >>>>>> If the refresh operation takes a long time, there may be good=20 >>>>>> routeing reasons to arrange for some route changes to be sent to=20 >>>>>> the peer "early" -- that is to send announcements which do not=20 >>>>>> contribute to the refresh, but which are important enough to=20 >>>>>> warrant delaying the end of the refresh. That could be a matter=20 >>>>>> for >>>>>> recommendation(s) in the standard. >>>>>>=20 >>>>>> NB: given that the timing of the EoRR is tied to the state of the=20 >>>>>> Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. >>>>>> At the beginning of the initial update, the Restarting and=20 >>>>>> Receiving speakers have: >>>>>>=20 >>>>>> Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out >>>>>>=20 >>>>>> Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In >>>>>>=20 >>>>>> Now suppose (bonkers or otherwise) the receiving speaker sends an=20 >>>>>> RRQ part way through the initial update. The restarting speaker=20 >>>>>> responds with BoRR, everything in its Adj-RIB-Out, and EoRR --=20 >>>>>> per specification. The receiving speaker sees the EoRR, and=20 >>>>>> flushes stale. Unfortunately, if the restarting speaker has not=20 >>>>>> yet fully populated its Adj-RIB-Out, then many further routes=20 >>>>>> will be sent before the EoR falls due -- but the receiving=20 >>>>>> speaker has already flushed their tiny posteriors :-( >>>>>>=20 >>>>>> I am coming to the view that route-refresh during a Graceful=20 >>>>>> Restart initial update is a horse of a different colour altogether. >>>>>>=20 >>>>>> [So the assumption that EoRR and EoR are triggered by the same=20 >>>>>> thing was completely wrong, and I apologise for it.] >>>>>>=20 >>>>>> Chris >>>>>>=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 >>>> >>>>_______________________________________________ >>>>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 jie.dong@huawei.com Wed Jan 29 00:22:40 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0251A044F for ; Wed, 29 Jan 2014 00:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COydLqob9WGi for ; Wed, 29 Jan 2014 00:22:36 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A15071A02E6 for ; Wed, 29 Jan 2014 00:22:35 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDA93495; Wed, 29 Jan 2014 08:22:31 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 29 Jan 2014 08:22:11 +0000 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 29 Jan 2014 08:22:29 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.51]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Wed, 29 Jan 2014 16:22:26 +0800 From: "Dongjie (Jimmy)" To: Robert Raszuk Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPF5KdKHMolEg8TF26AxOKep0T6JqRMOhAgADFQgCAAAwAgIAAC4YAgAARhoCAABvfAIAABfyAgAAe94CAABsuAIABU5kAgAAED4CAAX72AIAABbyAgAFQw7D//5SZAIAAhlqAgACM4rD//528gIAEdenQ Date: Wed, 29 Jan 2014 08:22:25 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927335C6B18@nkgeml512-mbx.china.huawei.com> References: <00AB3F7F-5E33-4533-96C7-E7F75A3E76CB@ericsson.com> <76CD132C3ADEF848BD84D028D243C927335C435C@nkgeml512-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.194.62] Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C927335C6B18nkgeml512mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Keyur Patel \(keyupate\)" , "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 08:22:40 -0000 --_000_76CD132C3ADEF848BD84D028D243C927335C6B18nkgeml512mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Robert, Agree that in these cases the RRQ cannot be ignored, so postpone may be a b= etter choice. While IMO stop the initial update and start over may delay the initial conv= ergence, and as you said it also relates to update group processing. What = do you think about the new text provided by Keyur? Best regards, Jie From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Rasz= uk Sent: Sunday, January 26, 2014 11:03 PM To: Dongjie (Jimmy) Cc: Keyur Patel (keyupate); Jakob Heitz; idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Jie, I think it actually very easy to say that initial update can not ever guara= ntee that RRQ received during its sending may meet the peer's need. Example 1: SAFI 128 - During receiving initial update from RR to PE new VRF got added = with new RT import. Unfortunately those updates received within initial upd= ate were already dropped as not interesting by the PE. RR must resend full = table after completed initial update. (Of course this is the case where the= re is no RTC and that's why RTC helps a lot here by incremental nature). Example 2: SAFI 1 - Operator has modified inbound policy on EBGP peer during processin= g of incoming updates and those originally were dropped. No soft reconfig i= n set. Conclusion: RRQ can not ever be ignored. Sure they can be delayed or batched (case of m= ultiple peers within the same update/peer group) sending near RRQs (cluster= of PEs got provisioned from central management station). But as Keyur alre= ady mentioned those are rather standard local implementation optimizations. Question: Does it maybe make sense to stop initial update when receiving RRQ from a p= eer and start over ? Of course if peer is part of large update group it wou= ld have to be removed dynamically from it so other members are not delayed.= In any case I think this does not impact the spec but the implementation. Cheers, R. On Sun, Jan 26, 2014 at 7:13 PM, Dongjie (Jimmy) > wrote: Hi Keyur, Jakob, Agree that "postpone" may be better. The point is we could avoid the compli= cated cases/considerations of performing route refresh during initial updat= e:) For "ignore", I was thinking of scenarios in which the route refresh requir= ement may already be met by the initial update, while I'd admit it is hard = to say... Best regards, Jie -----Original Message----- From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] Sent: Sunday, January 26, 2014 8:30 PM To: Jakob Heitz; Dongjie (Jimmy) Cc: idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Jie, I agree with Jakob. You could make it *an implementation behavior* to postp= one the route refresh reply. Regards, Keyur On 1/26/14 1:29 AM, "Jakob Heitz" > wrote: >You can definitely not ignore it, but you could postpone it. > >-- >Jakob Heitz. > >> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" > >>wrote: >> >> After reading the analyses in this thread, my personal feeling is >>maybe we should avoid the interleaving between GR initial update and >>route refresh/enhanced route refresh, since the initial update is just >>sending the whole Adj-RIB-Out, there is no obvious advantage to start >>a route refresh/enhance route refresh during it. So a speaker should >>ignore the RRQ received during the initial update. Thoughts? >> >> Best regards, >> Jie >> >> -----Original Message----- >> From: Idr [mailto:idr-bounces@ietf.org] On = Behalf Of Jakob Heitz >> Sent: Saturday, January 25, 2014 10:48 PM >> To: Chris Hall; idr@ietf.org >> Subject: Re: [Idr] WG LC for >> draft-ietf-idr-bgp-enhanced-route-refresh >> >> RFCs are written for coders "practiced" in the art". >> If anyone sends an EoRR before the adj-RIB-out is fully populated, >>then it's a BUG. >> This does not need to be said. >> >> Personally, I believe a route refresh request should not be honored >>until GR is complete. >> Also, I don't believe a timer for the receipt of EoRR is necessary, >>because the EoRR is guaranteed. >> Guaranteed means "unless the session drops first". >> -- >> >> Jakob Heitz. >> >> ________________________________________ >> From: Chris Hall [chris.hall@highwayman.com] >> Sent: Saturday, 25 January 2014 11:27 AM >> To: idr@ietf.org >> Cc: Jakob Heitz >> Subject: RE: [Idr] WG LC for >> draft-ietf-idr-bgp-enhanced-route-refresh >> >> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): >> ... >>> Silence means don't do it. >> >> Hmmm.... as a principle I'm more comfortable with "that which isn't >>prohibited is permitted".... >> >>> You would definitely NOT want BoRR to flush old stales. >> >> ....but, given the definite requirement, and given that the current >>precedent for "marking stale" does flush old stale, then a few words >>for the avoidance of doubt ? >> >>> Restarting the timer might be a good idea. >> >> I dunno... a route which remains stale for "a long time" is, of >>course, a candidate for being withdrawn: so having started a timer the >>first time things are set stale, I would avoid extending that -- at >>least for Graceful Restart, where the whole withdraw thing has been "on-h= old" >>since the last session failed. For route-refresh I guess there's more >>of a presumption that stale routes will be refreshed sooner or later, >>and in the meantime they remain good. So if the route-refresh is >>(repeatedly) restarted for some reason, perhaps it is more reasonable >>to extend the flush deadline -- but avoid doing this indefinitely ? >> >> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I have >>built in Quagga prioritise route changes (pending changes and any that >>occur during the refresh) over refresh updates. This makes it more >>likely that remaining stale routes are still good. But the other end >>cannot know that. >> >> The paragraph in the draft discussing the "entire Adj-RIB-Out" >>defines that to be the entries present "at the start of the route >>refresh operation", and observes that these comprise both reachable >>and unreachable routes. [An "of" after "comprise" sets teeth on edge, >>BTW.] I'm really not sure what this paragraph is trying to tell me. >> The reference to unreachable routes appears to suggest that pending >>withdraws should be sent as part of the refresh -- so not left to the >>EoRR to implement at the end. The point at which the EoRR is sent is >>defined such that it excludes any Adj-RIB-Out entries added after the >>route-refresh started, but includes any which are changed during the >>process. It seems reasonable to delay any brand new reachable >>prefixes until after all previously announced ones have been refreshed >>and the EoRR sent -- if that's the intent here. Changes which occur >>before the refresh gets to a given entry are pretty naturally swept up >>by the refresh. Changes which occur after the refresh has gone past, >>could/should be deferred to after the EoRR ? Does it make a >>difference if the change is a withdraw ? (Of course MRAI may kick in her= e. Ah. >>MRAI and route-refresh, there's a topic !) >> >> I think the essence of the rule is that the EoRR should be sent once >>all prefixes previously advertised to the peer as reachable have been >>refreshed, ie announced or withdrawn (at least) once. Or, perhaps >>more strictly, not *before* those prefixes have *all* been announced >>once -- given that the EoRR will promptly bang un-advertised stuff on the= head. >>Even more strictly perhaps: not send EoRR *before* any withdraws >>implied by it are required or desirable. >> >> Depending on the implementation, a given sender may or may not be >>able to determine the minimum set of updates required before sending EoRR= . >> >> If the refresh operation takes a long time, there may be good >>routeing reasons to arrange for some route changes to be sent to the peer= "early" >>-- that is to send announcements which do not contribute to the >>refresh, but which are important enough to warrant delaying the end of >>the refresh. That could be a matter for recommendation(s) in the standar= d. >> >> NB: given that the timing of the EoRR is tied to the state of the >>Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. At >>the beginning of the initial update, the Restarting and Receiving >>speakers have: >> >> Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out >> >> Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In >> >> Now suppose (bonkers or otherwise) the receiving speaker sends an RRQ >>part way through the initial update. The restarting speaker responds >>with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specification. >> The receiving speaker sees the EoRR, and flushes stale. >>Unfortunately, if the restarting speaker has not yet fully populated >>its Adj-RIB-Out, then many further routes will be sent before the EoR >>falls due -- but the receiving speaker has already flushed their tiny >>posteriors :-( >> >> I am coming to the view that route-refresh during a Graceful Restart >>initial update is a horse of a different colour altogether. >> >> [So the assumption that EoRR and EoR are triggered by the same thing >>was completely wrong, and I apologise for it.] >> >> Chris >> >> _______________________________________________ >> 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_76CD132C3ADEF848BD84D028D243C927335C6B18nkgeml512mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Robert,

 = ;

Agree that= in these cases the RRQ cannot be ignored, so postpone may be a better choi= ce.

 = ;

While IMO = stop the initial update and start over may delay the initial convergence, a= nd as you said  it also relates to update group processing. What do you think about the new text provided by Keyur? =

 = ;

Best regards,

Jie

 = ;

From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Raszuk
Sent: Sunday, January 26, 2014 11:03 PM
To: Dongjie (Jimmy)
Cc: Keyur Patel (keyupate); Jakob Heitz; idr@ietf.org
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refre= sh

 

Hi Jie,

 

I think it actually very easy to say that initial update can= not ever guarantee that RRQ received during its sending may meet the peer'= s need.

 

Example 1:

 

SAFI 128 - During receiving initial update from RR to PE new= VRF got added with new RT import. Unfortunately those updates received wit= hin initial update were already dropped as not interesting by the PE. RR must resend full table after completed initial update. (Of c= ourse this is the case where there is no RTC and that's why RTC helps a lot= here by incremental nature). 

 

Example 2: 

 

SAFI 1 - Operator has modified inbound policy on EBGP peer d= uring processing of incoming updates and those originally were dropped. No = soft reconfig in set. 

 

Conclusion:

 

RRQ can not ever be ignored. Sure they can be delayed or bat= ched (case of multiple peers within the same update/peer group) sending nea= r RRQs (cluster of PEs got provisioned from central management station). But as Keyur already mentioned those are rather stand= ard local implementation optimizations. 

 

Question:

 

Does it maybe make sense to stop initial update when receivi= ng RRQ from a peer and start over ? Of course if peer is part of large upda= te group it would have to be removed dynamically from it so other members are not delayed. In any case I think this does no= t impact the spec but the implementation.

 

Cheers,
R.

 

 

 

On Sun, Jan 26, 2014 at 7:13 PM= , Dongjie (Jimmy) <jie.dong@huawei.com> wrote:

Hi Keyur, Jakob,

Agree that "postpone" may be better. The point is we could avoid = the complicated cases/considerations of performing route refresh during ini= tial update:)

For "ignore", I was thinking of scenarios in which the route refr= esh requirement may already be met by the initial update, while I'd admit i= t is hard to say...



Best regards,
Jie

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

From: Keyur Patel (keyupate) [m= ailto:keyupate@cisco.com]
Sent: Sunday, January 26, 2014 8:30 PM
To: Jakob Heitz; Dongjie (Jimmy)
Cc: idr@ietf.org
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Jie,

I agree with Jakob. You could make it *an implementation behavior* to postp= one the route refresh reply.


Regards,
Keyur

On 1/26/14 1:29 AM, "Jakob Heitz" <jakob.heitz@ericsson.com> wrote:

>You can definitely not ignore it, but you could postpone it.
>
>--
>Jakob Heitz.
>
>> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" <jie.dong@huawei.com>
>>wrote:
>>
>> After reading the analyses in this thread, my personal feeling is<= br> >>maybe we should avoid the interleaving between GR initial update an= d
>>route refresh/enhanced route refresh, since the initial update is j= ust
>>sending the whole Adj-RIB-Out, there is no obvious advantage to sta= rt
>>a route refresh/enhance route refresh during it. So a speaker shoul= d
>>ignore the RRQ received during the initial update. Thoughts?
>>
>> Best regards,
>> Jie
>>
>> -----Original Message-----
>> From: Idr [mailto:idr-boun= ces@ietf.org] On Behalf Of Jakob Heitz
>> Sent: Saturday, January 25, 2014 10:48 PM
>> To: Chris Hall; idr@ietf.org >> Subject: Re: [Idr] WG LC for
>> draft-ietf-idr-bgp-enhanced-route-refresh
>>
>> RFCs are written for coders "practiced" in the art"= .
>> If anyone sends an EoRR before the adj-RIB-out is fully populated,=
>>then it's a BUG.
>> This does not need to be said.
>>
>> Personally, I believe a route refresh request should not be honore= d
>>until GR is complete.
>> Also, I don't believe a timer for the receipt of EoRR is necessary= ,
>>because the EoRR is guaranteed.
>> Guaranteed means "unless the session drops first".
>> --
>>
>> Jakob Heitz.
>>
>> ________________________________________
>> From: Chris Hall [chr= is.hall@highwayman.com]
>> Sent: Saturday, 25 January 2014 11:27 AM
>> To: idr@ietf.org
>> Cc: Jakob Heitz
>> Subject: RE: [Idr] WG LC for
>> draft-ietf-idr-bgp-enhanced-route-refresh
>>
>> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37):
>> ...
>>> Silence means don't do it.
>>
>> Hmmm.... as a principle I'm more comfortable with "that which= isn't
>>prohibited is permitted"....
>>
>>> You would definitely NOT want BoRR to flush old stales.
>>
>> ....but, given the definite requirement, and given that the curren= t
>>precedent for "marking stale" does flush old stale, then = a few words
>>for the avoidance of doubt ?
>>
>>> Restarting the timer might be a good idea.
>>
>> I dunno... a route which remains stale for "a long time"= is, of
>>course, a candidate for being withdrawn: so having started a timer = the
>>first time things are set stale, I would avoid extending that -- at=
>>least for Graceful Restart, where the whole withdraw thing has been= "on-hold"
>>since the last session failed.  For route-refresh I guess ther= e's more
>>of a presumption that stale routes will be refreshed sooner or late= r,
>>and in the meantime they remain good.  So if the route-refresh= is
>>(repeatedly) restarted for some reason, perhaps it is more reasonab= le
>>to extend the flush deadline -- but avoid doing this indefinitely ?=
>>
>> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I ha= ve
>>built in Quagga prioritise route changes (pending changes and any t= hat
>>occur during the refresh) over refresh updates.  This makes it= more
>>likely that remaining stale routes are still good.  But the ot= her end
>>cannot know that.
>>
>> The paragraph in the draft discussing the "entire Adj-RIB-Out= "
>>defines that to be the entries present "at the start of the ro= ute
>>refresh operation", and observes that these comprise both reac= hable
>>and unreachable routes.  [An "of" after "compri= se" sets teeth on edge,
>>BTW.]  I'm really not sure what this paragraph is trying to te= ll me.
>> The reference to unreachable routes appears to suggest that pendin= g
>>withdraws should be sent as part of the refresh -- so not left to t= he
>>EoRR to implement at the end.  The point at which the EoRR is = sent is
>>defined such that it excludes any Adj-RIB-Out entries added after t= he
>>route-refresh started, but includes any which are changed during th= e
>>process.  It seems reasonable to delay any brand new reachable=
>>prefixes until after all previously announced ones have been refres= hed
>>and the EoRR sent -- if that's the intent here.  Changes which= occur
>>before the refresh gets to a given entry are pretty naturally swept= up
>>by the refresh.  Changes which occur after the refresh has gon= e past,
>>could/should be deferred to after the EoRR ?  Does it make a >>difference if the change is a withdraw ?  (Of course MRAI may = kick in here.  Ah.
>>MRAI and route-refresh, there's a topic !)
>>
>> I think the essence of the rule is that the EoRR should be sent on= ce
>>all prefixes previously advertised to the peer as reachable have be= en
>>refreshed, ie announced or withdrawn (at least) once.  Or, per= haps
>>more strictly, not *before* those prefixes have *all* been announce= d
>>once -- given that the EoRR will promptly bang un-advertised stuff = on the head.
>>Even more strictly perhaps: not send EoRR *before* any withdraws >>implied by it are required or desirable.
>>
>> Depending on the implementation, a given sender may or may not be<= br> >>able to determine the minimum set of updates required before sendin= g EoRR.
>>
>> If the refresh operation takes a long time, there may be good
>>routeing reasons to arrange for some route changes to be sent to th= e peer "early"
>>-- that is to send announcements which do not contribute to the
>>refresh, but which are important enough to warrant delaying the end= of
>>the refresh.  That could be a matter for recommendation(s) in = the standard.
>>
>> NB: given that the timing of the EoRR is tied to the state of the<= br> >>Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. &= nbsp;At
>>the beginning of the initial update, the Restarting and Receiving >>speakers have:
>>
>>  Restarting:  Empty Adj-RIB-In   Empty Adj-RIB-Out<= br> >>
>>  Receiving:   Empty Adj-RIB-Out  Stale Adj-RIB-In >>
>> Now suppose (bonkers or otherwise) the receiving speaker sends an = RRQ
>>part way through the initial update.  The restarting speaker r= esponds
>>with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specifica= tion.
>> The receiving speaker sees the EoRR, and flushes stale.
>>Unfortunately, if the restarting speaker has not yet fully populate= d
>>its Adj-RIB-Out, then many further routes will be sent before the E= oR
>>falls due -- but the receiving speaker has already flushed their ti= ny
>>posteriors :-(
>>
>> I am coming to the view that route-refresh during a Graceful Resta= rt
>>initial update is a horse of a different colour altogether.
>>
>> [So the assumption that EoRR and EoR are triggered by the same thi= ng
>>was completely wrong, and I apologise for it.]
>>
>> Chris
>>
>> _______________________________________________
>> 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
htt= ps://www.ietf.org/mailman/listinfo/idr

 

--_000_76CD132C3ADEF848BD84D028D243C927335C6B18nkgeml512mbxchi_-- From rraszuk@gmail.com Wed Jan 29 01:15:09 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39ECA1A0364 for ; Wed, 29 Jan 2014 01:15:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFX4Yx5Cw9Gf for ; Wed, 29 Jan 2014 01:15:05 -0800 (PST) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 17FEF1A037D for ; Wed, 29 Jan 2014 01:15:04 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id at1so1808248iec.36 for ; Wed, 29 Jan 2014 01:15:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=vA0/aZ0KyVUch69UVtHCfAf1/wXgH17gVOBEpySqbv4=; b=Ew1QE/rDbSs6O6/j0Z7qsAt+OKuvB44eHZdzsj9YNlEm5cueOYT6t6Y4Fqme0xn8+y yYh0b2+yUVQ6MeCEz3oUZVPUcLC3LAH2qX+HKhakUzenn9ZuVrgK6DHlCIzSPIylPEEd VH4Pqrab4saADbpNecbtMA4TqYeo916ysUoX/QOx1zveWXYPnxmNZQABnyK8vrynTdQ7 T/2zGqXqMAa7MO23QyVcIKURMYCJYMOlimSt665LWaClEboUvy5iFNLSGr/0vMCdzF1R 8+MQSw1onst2ywGAnTDTeIqo/svHb/7ElNN8tpjsCj1V9X0kjounTvdGLIm/rU5UE3Hf 7FRQ== MIME-Version: 1.0 X-Received: by 10.50.20.74 with SMTP id l10mr27844526ige.9.1390986902016; Wed, 29 Jan 2014 01:15:02 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.212.8 with HTTP; Wed, 29 Jan 2014 01:15:01 -0800 (PST) In-Reply-To: <76CD132C3ADEF848BD84D028D243C927335C6B18@nkgeml512-mbx.china.huawei.com> References: <00AB3F7F-5E33-4533-96C7-E7F75A3E76CB@ericsson.com> <76CD132C3ADEF848BD84D028D243C927335C435C@nkgeml512-mbx.china.huawei.com> <76CD132C3ADEF848BD84D028D243C927335C6B18@nkgeml512-mbx.china.huawei.com> Date: Wed, 29 Jan 2014 10:15:01 +0100 X-Google-Sender-Auth: 50rYRf8VGwpXlqUeNyzd6cNoVmk Message-ID: From: Robert Raszuk To: "Dongjie (Jimmy)" Content-Type: multipart/alternative; boundary=047d7bd752702e9cd904f1186048 Cc: "Keyur Patel \(keyupate\)" , "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 09:15:09 -0000 --047d7bd752702e9cd904f1186048 Content-Type: text/plain; charset=ISO-8859-1 Hi Jimmy and all, I think Enke and Keyur's proposed text with help from Jakob makes the behavior simplified and deterministic to hold on BoRR till first EoR is seen. IMHO it should be also spelled out what is the expected sequence error handling here ... I think not following "MUST NOT" shall implicitly result in entire session drop and complete restart ? Any error code ? Best, R. On Wed, Jan 29, 2014 at 9:22 AM, Dongjie (Jimmy) wrote: > Hi Robert, > > > > Agree that in these cases the RRQ cannot be ignored, so postpone may be a > better choice. > > > > While IMO stop the initial update and start over may delay the initial > convergence, and as you said it also relates to update group processing. > What do you think about the new text provided by Keyur? > > > > Best regards, > > Jie > > > > *From:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Robert > Raszuk > *Sent:* Sunday, January 26, 2014 11:03 PM > *To:* Dongjie (Jimmy) > *Cc:* Keyur Patel (keyupate); Jakob Heitz; idr@ietf.org > > *Subject:* Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh > > > > Hi Jie, > > > > I think it actually very easy to say that initial update can not ever > guarantee that RRQ received during its sending may meet the peer's need. > > > > Example 1: > > > > SAFI 128 - During receiving initial update from RR to PE new VRF got added > with new RT import. Unfortunately those updates received within initial > update were already dropped as not interesting by the PE. RR must resend > full table after completed initial update. (Of course this is the case > where there is no RTC and that's why RTC helps a lot here by incremental > nature). > > > > Example 2: > > > > SAFI 1 - Operator has modified inbound policy on EBGP peer during > processing of incoming updates and those originally were dropped. No soft > reconfig in set. > > > > Conclusion: > > > > RRQ can not ever be ignored. Sure they can be delayed or batched (case of > multiple peers within the same update/peer group) sending near RRQs > (cluster of PEs got provisioned from central management station). But as > Keyur already mentioned those are rather standard local implementation > optimizations. > > > > Question: > > > > Does it maybe make sense to stop initial update when receiving RRQ from a > peer and start over ? Of course if peer is part of large update group it > would have to be removed dynamically from it so other members are not > delayed. In any case I think this does not impact the spec but the > implementation. > > > > Cheers, > R. > > > > > > > > On Sun, Jan 26, 2014 at 7:13 PM, Dongjie (Jimmy) > wrote: > > Hi Keyur, Jakob, > > Agree that "postpone" may be better. The point is we could avoid the > complicated cases/considerations of performing route refresh during initial > update:) > > For "ignore", I was thinking of scenarios in which the route refresh > requirement may already be met by the initial update, while I'd admit it is > hard to say... > > > > Best regards, > Jie > > -----Original Message----- > > From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] > Sent: Sunday, January 26, 2014 8:30 PM > To: Jakob Heitz; Dongjie (Jimmy) > Cc: idr@ietf.org > Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh > > Jie, > > I agree with Jakob. You could make it *an implementation behavior* to > postpone the route refresh reply. > > > Regards, > Keyur > > On 1/26/14 1:29 AM, "Jakob Heitz" wrote: > > >You can definitely not ignore it, but you could postpone it. > > > >-- > >Jakob Heitz. > > > >> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" > >>wrote: > >> > >> After reading the analyses in this thread, my personal feeling is > >>maybe we should avoid the interleaving between GR initial update and > >>route refresh/enhanced route refresh, since the initial update is just > >>sending the whole Adj-RIB-Out, there is no obvious advantage to start > >>a route refresh/enhance route refresh during it. So a speaker should > >>ignore the RRQ received during the initial update. Thoughts? > >> > >> Best regards, > >> Jie > >> > >> -----Original Message----- > >> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz > >> Sent: Saturday, January 25, 2014 10:48 PM > >> To: Chris Hall; idr@ietf.org > >> Subject: Re: [Idr] WG LC for > >> draft-ietf-idr-bgp-enhanced-route-refresh > >> > >> RFCs are written for coders "practiced" in the art". > >> If anyone sends an EoRR before the adj-RIB-out is fully populated, > >>then it's a BUG. > >> This does not need to be said. > >> > >> Personally, I believe a route refresh request should not be honored > >>until GR is complete. > >> Also, I don't believe a timer for the receipt of EoRR is necessary, > >>because the EoRR is guaranteed. > >> Guaranteed means "unless the session drops first". > >> -- > >> > >> Jakob Heitz. > >> > >> ________________________________________ > >> From: Chris Hall [chris.hall@highwayman.com] > >> Sent: Saturday, 25 January 2014 11:27 AM > >> To: idr@ietf.org > >> Cc: Jakob Heitz > >> Subject: RE: [Idr] WG LC for > >> draft-ietf-idr-bgp-enhanced-route-refresh > >> > >> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): > >> ... > >>> Silence means don't do it. > >> > >> Hmmm.... as a principle I'm more comfortable with "that which isn't > >>prohibited is permitted".... > >> > >>> You would definitely NOT want BoRR to flush old stales. > >> > >> ....but, given the definite requirement, and given that the current > >>precedent for "marking stale" does flush old stale, then a few words > >>for the avoidance of doubt ? > >> > >>> Restarting the timer might be a good idea. > >> > >> I dunno... a route which remains stale for "a long time" is, of > >>course, a candidate for being withdrawn: so having started a timer the > >>first time things are set stale, I would avoid extending that -- at > >>least for Graceful Restart, where the whole withdraw thing has been > "on-hold" > >>since the last session failed. For route-refresh I guess there's more > >>of a presumption that stale routes will be refreshed sooner or later, > >>and in the meantime they remain good. So if the route-refresh is > >>(repeatedly) restarted for some reason, perhaps it is more reasonable > >>to extend the flush deadline -- but avoid doing this indefinitely ? > >> > >> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I have > >>built in Quagga prioritise route changes (pending changes and any that > >>occur during the refresh) over refresh updates. This makes it more > >>likely that remaining stale routes are still good. But the other end > >>cannot know that. > >> > >> The paragraph in the draft discussing the "entire Adj-RIB-Out" > >>defines that to be the entries present "at the start of the route > >>refresh operation", and observes that these comprise both reachable > >>and unreachable routes. [An "of" after "comprise" sets teeth on edge, > >>BTW.] I'm really not sure what this paragraph is trying to tell me. > >> The reference to unreachable routes appears to suggest that pending > >>withdraws should be sent as part of the refresh -- so not left to the > >>EoRR to implement at the end. The point at which the EoRR is sent is > >>defined such that it excludes any Adj-RIB-Out entries added after the > >>route-refresh started, but includes any which are changed during the > >>process. It seems reasonable to delay any brand new reachable > >>prefixes until after all previously announced ones have been refreshed > >>and the EoRR sent -- if that's the intent here. Changes which occur > >>before the refresh gets to a given entry are pretty naturally swept up > >>by the refresh. Changes which occur after the refresh has gone past, > >>could/should be deferred to after the EoRR ? Does it make a > >>difference if the change is a withdraw ? (Of course MRAI may kick in > here. Ah. > >>MRAI and route-refresh, there's a topic !) > >> > >> I think the essence of the rule is that the EoRR should be sent once > >>all prefixes previously advertised to the peer as reachable have been > >>refreshed, ie announced or withdrawn (at least) once. Or, perhaps > >>more strictly, not *before* those prefixes have *all* been announced > >>once -- given that the EoRR will promptly bang un-advertised stuff on > the head. > >>Even more strictly perhaps: not send EoRR *before* any withdraws > >>implied by it are required or desirable. > >> > >> Depending on the implementation, a given sender may or may not be > >>able to determine the minimum set of updates required before sending > EoRR. > >> > >> If the refresh operation takes a long time, there may be good > >>routeing reasons to arrange for some route changes to be sent to the > peer "early" > >>-- that is to send announcements which do not contribute to the > >>refresh, but which are important enough to warrant delaying the end of > >>the refresh. That could be a matter for recommendation(s) in the > standard. > >> > >> NB: given that the timing of the EoRR is tied to the state of the > >>Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. At > >>the beginning of the initial update, the Restarting and Receiving > >>speakers have: > >> > >> Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out > >> > >> Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In > >> > >> Now suppose (bonkers or otherwise) the receiving speaker sends an RRQ > >>part way through the initial update. The restarting speaker responds > >>with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specification. > >> The receiving speaker sees the EoRR, and flushes stale. > >>Unfortunately, if the restarting speaker has not yet fully populated > >>its Adj-RIB-Out, then many further routes will be sent before the EoR > >>falls due -- but the receiving speaker has already flushed their tiny > >>posteriors :-( > >> > >> I am coming to the view that route-refresh during a Graceful Restart > >>initial update is a horse of a different colour altogether. > >> > >> [So the assumption that EoRR and EoR are triggered by the same thing > >>was completely wrong, and I apologise for it.] > >> > >> Chris > >> > >> _______________________________________________ > >> 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 > > > --047d7bd752702e9cd904f1186048 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Jimmy and all,

I think Enke and Keyur's proposed text with help from Jakob makes the b= ehavior simplified and deterministic to hold on BoRR till first EoR is seen= .

IMHO it should be also spelled out what is the expe= cted sequence error handling here ... I think not following "MUST NOT&= quot; shall implicitly result in entire session drop and complete restart ?= Any error code ?

Best,
R.



On Wed, Jan 29, 2014 at 9:22 AM, Dongjie (Jimmy) <<= a href=3D"mailto:jie.dong@huawei.com" target=3D"_blank">jie.dong@huawei.com= > wrote:

Hi Robert,

=A0=

Agree that= in these cases the RRQ cannot be ignored, so postpone may be a better choi= ce.

=A0=

While IMO = stop the initial update and start over may delay the initial convergence, a= nd as you said =A0it also relates to update group processing. What do you think about the new text provided by Keyur?

=A0=

Best regards,=

Jie

=A0=

From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Raszuk
Sent: Sunday, January 26, 2014 11:03 PM
To: Dongjie (Jimmy)
Cc: Keyur Patel (keyupate); Jakob Heitz; idr@ietf.org

Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refre= sh

=A0

Hi Jie,

=A0

I think it actually very easy to say that initial update can= not ever guarantee that RRQ received during its sending may meet the peer&= #39;s need.

=A0

Example 1:

=A0

SAFI 128 - During receiving initial update from RR to PE new= VRF got added with new RT import. Unfortunately those updates received wit= hin initial update were already dropped as not interesting by the PE. RR must resend full table after completed initial update. (Of c= ourse this is the case where there is no RTC and that's why RTC helps a= lot here by incremental nature).=A0

=A0

Example 2:=A0

=A0

SAFI 1 - Operator has modified inbound policy on EBGP peer d= uring processing of incoming updates and those originally were dropped. No = soft reconfig in set.=A0

=A0

Conclusion:

=A0

RRQ can not ever be ignored. Sure they can be delayed or bat= ched (case of multiple peers within the same update/peer group) sending nea= r RRQs (cluster of PEs got provisioned from central management station). But as Keyur already mentioned those are rather stand= ard local implementation optimizations.=A0

=A0

Question:

=A0

Does it maybe make sense to stop initial update when receivi= ng RRQ from a peer and start over ? Of course if peer is part of large upda= te group it would have to be removed dynamically from it so other members are not delayed. In any case I think this does no= t impact the spec but the implementation.

=A0

Cheers,
R.

=A0

=A0

=A0

On Sun, Jan 26, 2014 at 7:13 PM= , Dongjie (Jimmy) <jie.dong@huawei.com> wrote:

Hi Keyur, Jakob,

Agree that "postpone" may be better. The point is we could avoid = the complicated cases/considerations of performing route refresh during ini= tial update:)

For "ignore", I was thinking of scenarios in which the route refr= esh requirement may already be met by the initial update, while I'd adm= it it is hard to say...



Best regards,
Jie

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

From: Keyur Patel (keyupate) [m= ailto:keyupate@cisc= o.com]
Sent: Sunday, January 26, 2014 8:30 PM
To: Jakob Heitz; Dongjie (Jimmy)
Cc: idr@ietf.org
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Jie,

I agree with Jakob. You could make it *an implementation behavior* to postp= one the route refresh reply.


Regards,
Keyur

On 1/26/14 1:29 AM, "Jakob Heitz" <jakob.heitz@ericsson.com> wrote:<= br>
>You can definitely not ignore it, but you could postpone it.
>
>--
>Jakob Heitz.
>
>> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" <jie.dong@huawei.com>
>>wrote:
>>
>> After reading the analyses in this thread, my personal feeling is<= br> >>maybe we should avoid the interleaving between GR initial update an= d
>>route refresh/enhanced route refresh, since the initial update is j= ust
>>sending the whole Adj-RIB-Out, there is no obvious advantage to sta= rt
>>a route refresh/enhance route refresh during it. So a speaker shoul= d
>>ignore the RRQ received during the initial update. Thoughts?
>>
>> Best regards,
>> Jie
>>
>> -----Original Message-----
>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz
>> Sent: Saturday, January 25, 2014 10:48 PM
>> To: Chris Hall; = idr@ietf.org
>> Subject: Re: [Idr] WG LC for
>> draft-ietf-idr-bgp-enhanced-route-refresh
>>
>> RFCs are written for coders "practiced" in the art"= .
>> If anyone sends an EoRR before the adj-RIB-out is fully populated,=
>>then it's a BUG.
>> This does not need to be said.
>>
>> Personally, I believe a route refresh request should not be honore= d
>>until GR is complete.
>> Also, I don't believe a timer for the receipt of EoRR is neces= sary,
>>because the EoRR is guaranteed.
>> Guaranteed means "unless the session drops first".
>> --
>>
>> Jakob Heitz.
>>
>> ________________________________________
>> From: Chris Hall [chris.hall@highwayman.com]
>> Sent: Saturday, 25 January 2014 11:27 AM
>> To: idr@ietf.org=
>> Cc: Jakob Heitz
>> Subject: RE: [Idr] WG LC for
>> draft-ietf-idr-bgp-enhanced-route-refresh
>>
>> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37):
>> ...
>>> Silence means don't do it.
>>
>> Hmmm.... as a principle I'm more comfortable with "that w= hich isn't
>>prohibited is permitted"....
>>
>>> You would definitely NOT want BoRR to flush old stales.
>>
>> ....but, given the definite requirement, and given that the curren= t
>>precedent for "marking stale" does flush old stale, then = a few words
>>for the avoidance of doubt ?
>>
>>> Restarting the timer might be a good idea.
>>
>> I dunno... a route which remains stale for "a long time"= is, of
>>course, a candidate for being withdrawn: so having started a timer = the
>>first time things are set stale, I would avoid extending that -- at=
>>least for Graceful Restart, where the whole withdraw thing has been= "on-hold"
>>since the last session failed. =A0For route-refresh I guess there&#= 39;s more
>>of a presumption that stale routes will be refreshed sooner or late= r,
>>and in the meantime they remain good. =A0So if the route-refresh is=
>>(repeatedly) restarted for some reason, perhaps it is more reasonab= le
>>to extend the flush deadline -- but avoid doing this indefinitely ?=
>>
>> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I ha= ve
>>built in Quagga prioritise route changes (pending changes and any t= hat
>>occur during the refresh) over refresh updates. =A0This makes it mo= re
>>likely that remaining stale routes are still good. =A0But the other= end
>>cannot know that.
>>
>> The paragraph in the draft discussing the "entire Adj-RIB-Out= "
>>defines that to be the entries present "at the start of the ro= ute
>>refresh operation", and observes that these comprise both reac= hable
>>and unreachable routes. =A0[An "of" after "comprise&= quot; sets teeth on edge,
>>BTW.] =A0I'm really not sure what this paragraph is trying to t= ell me.
>> The reference to unreachable routes appears to suggest that pendin= g
>>withdraws should be sent as part of the refresh -- so not left to t= he
>>EoRR to implement at the end. =A0The point at which the EoRR is sen= t is
>>defined such that it excludes any Adj-RIB-Out entries added after t= he
>>route-refresh started, but includes any which are changed during th= e
>>process. =A0It seems reasonable to delay any brand new reachable >>prefixes until after all previously announced ones have been refres= hed
>>and the EoRR sent -- if that's the intent here. =A0Changes whic= h occur
>>before the refresh gets to a given entry are pretty naturally swept= up
>>by the refresh. =A0Changes which occur after the refresh has gone p= ast,
>>could/should be deferred to after the EoRR ? =A0Does it make a
>>difference if the change is a withdraw ? =A0(Of course MRAI may kic= k in here. =A0Ah.
>>MRAI and route-refresh, there's a topic !)
>>
>> I think the essence of the rule is that the EoRR should be sent on= ce
>>all prefixes previously advertised to the peer as reachable have be= en
>>refreshed, ie announced or withdrawn (at least) once. =A0Or, perhap= s
>>more strictly, not *before* those prefixes have *all* been announce= d
>>once -- given that the EoRR will promptly bang un-advertised stuff = on the head.
>>Even more strictly perhaps: not send EoRR *before* any withdraws >>implied by it are required or desirable.
>>
>> Depending on the implementation, a given sender may or may not be<= br> >>able to determine the minimum set of updates required before sendin= g EoRR.
>>
>> If the refresh operation takes a long time, there may be good
>>routeing reasons to arrange for some route changes to be sent to th= e peer "early"
>>-- that is to send announcements which do not contribute to the
>>refresh, but which are important enough to warrant delaying the end= of
>>the refresh. =A0That could be a matter for recommendation(s) in the= standard.
>>
>> NB: given that the timing of the EoRR is tied to the state of the<= br> >>Adj-RIB-Out, I'm not sure about the Graceful Restart assumption= s. =A0At
>>the beginning of the initial update, the Restarting and Receiving >>speakers have:
>>
>> =A0Restarting: =A0Empty Adj-RIB-In =A0 Empty Adj-RIB-Out
>>
>> =A0Receiving: =A0 Empty Adj-RIB-Out =A0Stale Adj-RIB-In
>>
>> Now suppose (bonkers or otherwise) the receiving speaker sends an = RRQ
>>part way through the initial update. =A0The restarting speaker resp= onds
>>with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specifica= tion.
>> The receiving speaker sees the EoRR, and flushes stale.
>>Unfortunately, if the restarting speaker has not yet fully populate= d
>>its Adj-RIB-Out, then many further routes will be sent before the E= oR
>>falls due -- but the receiving speaker has already flushed their ti= ny
>>posteriors :-(
>>
>> I am coming to the view that route-refresh during a Graceful Resta= rt
>>initial update is a horse of a different colour altogether.
>>
>> [So the assumption that EoRR and EoR are triggered by the same thi= ng
>>was completely wrong, and I apologise for it.]
>>
>> Chris
>>
>> _______________________________________________
>> 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
htt= ps://www.ietf.org/mailman/listinfo/idr

=A0


--047d7bd752702e9cd904f1186048-- From bruno.decraene@orange.com Wed Jan 29 01:51:13 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB89C1A0437 for ; Wed, 29 Jan 2014 01:51:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnDaW7Bhpp-G for ; Wed, 29 Jan 2014 01:51:06 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 643D81A0372 for ; Wed, 29 Jan 2014 01:51:05 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id D868818C901; Wed, 29 Jan 2014 10:51:01 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id BFCD24C085; Wed, 29 Jan 2014 10:51:01 +0100 (CET) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Wed, 29 Jan 2014 10:51:01 +0100 From: To: Robert Raszuk , "Keyur Patel (keyupate)" Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPHNKg3MXmo8KxoESEhujQiGLM/ZqbbmRA Date: Wed, 29 Jan 2014 09:51:00 +0000 Message-ID: <6650_1390989061_52E8CF05_6650_399_1_53C29892C857584299CBF5D05346208A070DFED8@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <00AB3F7F-5E33-4533-96C7-E7F75A3E76CB@ericsson.com> <76CD132C3ADEF848BD84D028D243C927335C435C@nkgeml512-mbx.china.huawei.com> <76CD132C3ADEF848BD84D028D243C927335C6B18@nkgeml512-mbx.china.huawei.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A070DFED8PEXCVZYM11corpo_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.20.60015 Cc: "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 09:51:13 -0000 --_000_53C29892C857584299CBF5D05346208A070DFED8PEXCVZYM11corpo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: Wednesday, January 29, 2014 10:15 AM To: Dongjie (Jimmy) Cc: Keyur Patel (keyupate); idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Jimmy and all, I think Enke and Keyur's proposed text with help from Jakob makes the behav= ior simplified and deterministic to hold on BoRR till first EoR is seen. IMHO it should be also spelled out what is the expected sequence error hand= ling here [Bruno] +1. And taking into account possible interaction with draft-ietf-i= dr-bgp-gr-notification BTW: "When the BGP speaker detects an error while processing a ROUTE-REFRESH mes= sage with a non-zero "Message Subtype" field, it MUST send a NOTIFICATION m= essage with Error Code "ROUTE-REFRESH Message Error"." Seems a priori not inline with the recommendation from draft-ietf-grow-ops-= reqs-for-bgp-error-handling (which is to limit the consequences of error ha= ndling). Are we sure that no error condition could be handled in a more fri= endly way? (e.g. if BoRR is not sent following a "normal route refresh requ= est" or if 2 BoRR are sent consecutively...) Thanks, Regards, Bruno ... I think not following "MUST NOT" shall implicitly result in entire sess= ion drop and complete restart ? Any error code ? Best, R. On Wed, Jan 29, 2014 at 9:22 AM, Dongjie (Jimmy) > wrote: Hi Robert, Agree that in these cases the RRQ cannot be ignored, so postpone may be a b= etter choice. While IMO stop the initial update and start over may delay the initial conv= ergence, and as you said it also relates to update group processing. What = do you think about the new text provided by Keyur? Best regards, Jie From: rraszuk@gmail.com [mailto:rraszuk@gmail.com= ] On Behalf Of Robert Raszuk Sent: Sunday, January 26, 2014 11:03 PM To: Dongjie (Jimmy) Cc: Keyur Patel (keyupate); Jakob Heitz; idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Jie, I think it actually very easy to say that initial update can not ever guara= ntee that RRQ received during its sending may meet the peer's need. Example 1: SAFI 128 - During receiving initial update from RR to PE new VRF got added = with new RT import. Unfortunately those updates received within initial upd= ate were already dropped as not interesting by the PE. RR must resend full = table after completed initial update. (Of course this is the case where the= re is no RTC and that's why RTC helps a lot here by incremental nature). Example 2: SAFI 1 - Operator has modified inbound policy on EBGP peer during processin= g of incoming updates and those originally were dropped. No soft reconfig i= n set. Conclusion: RRQ can not ever be ignored. Sure they can be delayed or batched (case of m= ultiple peers within the same update/peer group) sending near RRQs (cluster= of PEs got provisioned from central management station). But as Keyur alre= ady mentioned those are rather standard local implementation optimizations. Question: Does it maybe make sense to stop initial update when receiving RRQ from a p= eer and start over ? Of course if peer is part of large update group it wou= ld have to be removed dynamically from it so other members are not delayed.= In any case I think this does not impact the spec but the implementation. Cheers, R. On Sun, Jan 26, 2014 at 7:13 PM, Dongjie (Jimmy) > wrote: Hi Keyur, Jakob, Agree that "postpone" may be better. The point is we could avoid the compli= cated cases/considerations of performing route refresh during initial updat= e:) For "ignore", I was thinking of scenarios in which the route refresh requir= ement may already be met by the initial update, while I'd admit it is hard = to say... Best regards, Jie -----Original Message----- From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] Sent: Sunday, January 26, 2014 8:30 PM To: Jakob Heitz; Dongjie (Jimmy) Cc: idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Jie, I agree with Jakob. You could make it *an implementation behavior* to postp= one the route refresh reply. Regards, Keyur On 1/26/14 1:29 AM, "Jakob Heitz" > wrote: >You can definitely not ignore it, but you could postpone it. > >-- >Jakob Heitz. > >> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" > >>wrote: >> >> After reading the analyses in this thread, my personal feeling is >>maybe we should avoid the interleaving between GR initial update and >>route refresh/enhanced route refresh, since the initial update is just >>sending the whole Adj-RIB-Out, there is no obvious advantage to start >>a route refresh/enhance route refresh during it. So a speaker should >>ignore the RRQ received during the initial update. Thoughts? >> >> Best regards, >> Jie >> >> -----Original Message----- >> From: Idr [mailto:idr-bounces@ietf.org] On = Behalf Of Jakob Heitz >> Sent: Saturday, January 25, 2014 10:48 PM >> To: Chris Hall; idr@ietf.org >> Subject: Re: [Idr] WG LC for >> draft-ietf-idr-bgp-enhanced-route-refresh >> >> RFCs are written for coders "practiced" in the art". >> If anyone sends an EoRR before the adj-RIB-out is fully populated, >>then it's a BUG. >> This does not need to be said. >> >> Personally, I believe a route refresh request should not be honored >>until GR is complete. >> Also, I don't believe a timer for the receipt of EoRR is necessary, >>because the EoRR is guaranteed. >> Guaranteed means "unless the session drops first". >> -- >> >> Jakob Heitz. >> >> ________________________________________ >> From: Chris Hall [chris.hall@highwayman.com] >> Sent: Saturday, 25 January 2014 11:27 AM >> To: idr@ietf.org >> Cc: Jakob Heitz >> Subject: RE: [Idr] WG LC for >> draft-ietf-idr-bgp-enhanced-route-refresh >> >> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): >> ... >>> Silence means don't do it. >> >> Hmmm.... as a principle I'm more comfortable with "that which isn't >>prohibited is permitted".... >> >>> You would definitely NOT want BoRR to flush old stales. >> >> ....but, given the definite requirement, and given that the current >>precedent for "marking stale" does flush old stale, then a few words >>for the avoidance of doubt ? >> >>> Restarting the timer might be a good idea. >> >> I dunno... a route which remains stale for "a long time" is, of >>course, a candidate for being withdrawn: so having started a timer the >>first time things are set stale, I would avoid extending that -- at >>least for Graceful Restart, where the whole withdraw thing has been "on-h= old" >>since the last session failed. For route-refresh I guess there's more >>of a presumption that stale routes will be refreshed sooner or later, >>and in the meantime they remain good. So if the route-refresh is >>(repeatedly) restarted for some reason, perhaps it is more reasonable >>to extend the flush deadline -- but avoid doing this indefinitely ? >> >> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I have >>built in Quagga prioritise route changes (pending changes and any that >>occur during the refresh) over refresh updates. This makes it more >>likely that remaining stale routes are still good. But the other end >>cannot know that. >> >> The paragraph in the draft discussing the "entire Adj-RIB-Out" >>defines that to be the entries present "at the start of the route >>refresh operation", and observes that these comprise both reachable >>and unreachable routes. [An "of" after "comprise" sets teeth on edge, >>BTW.] I'm really not sure what this paragraph is trying to tell me. >> The reference to unreachable routes appears to suggest that pending >>withdraws should be sent as part of the refresh -- so not left to the >>EoRR to implement at the end. The point at which the EoRR is sent is >>defined such that it excludes any Adj-RIB-Out entries added after the >>route-refresh started, but includes any which are changed during the >>process. It seems reasonable to delay any brand new reachable >>prefixes until after all previously announced ones have been refreshed >>and the EoRR sent -- if that's the intent here. Changes which occur >>before the refresh gets to a given entry are pretty naturally swept up >>by the refresh. Changes which occur after the refresh has gone past, >>could/should be deferred to after the EoRR ? Does it make a >>difference if the change is a withdraw ? (Of course MRAI may kick in her= e. Ah. >>MRAI and route-refresh, there's a topic !) >> >> I think the essence of the rule is that the EoRR should be sent once >>all prefixes previously advertised to the peer as reachable have been >>refreshed, ie announced or withdrawn (at least) once. Or, perhaps >>more strictly, not *before* those prefixes have *all* been announced >>once -- given that the EoRR will promptly bang un-advertised stuff on the= head. >>Even more strictly perhaps: not send EoRR *before* any withdraws >>implied by it are required or desirable. >> >> Depending on the implementation, a given sender may or may not be >>able to determine the minimum set of updates required before sending EoRR. >> >> If the refresh operation takes a long time, there may be good >>routeing reasons to arrange for some route changes to be sent to the peer= "early" >>-- that is to send announcements which do not contribute to the >>refresh, but which are important enough to warrant delaying the end of >>the refresh. That could be a matter for recommendation(s) in the standar= d. >> >> NB: given that the timing of the EoRR is tied to the state of the >>Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. At >>the beginning of the initial update, the Restarting and Receiving >>speakers have: >> >> Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out >> >> Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In >> >> Now suppose (bonkers or otherwise) the receiving speaker sends an RRQ >>part way through the initial update. The restarting speaker responds >>with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specification. >> The receiving speaker sees the EoRR, and flushes stale. >>Unfortunately, if the restarting speaker has not yet fully populated >>its Adj-RIB-Out, then many further routes will be sent before the EoR >>falls due -- but the receiving speaker has already flushed their tiny >>posteriors :-( >> >> I am coming to the view that route-refresh during a Graceful Restart >>initial update is a horse of a different colour altogether. >> >> [So the assumption that EoRR and EoR are triggered by the same thing >>was completely wrong, and I apologise for it.] >> >> Chris >> >> _______________________________________________ >> 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 ___________________________________________________________________________= ______________________________________________ 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, 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 authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A070DFED8PEXCVZYM11corpo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,=

 <= /p>

 <= /p>

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Wednesday, January 29, 2014 10:15 AM
To: Dongjie (Jimmy)
Cc: Keyur Patel (keyupate); idr@ietf.org
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refre= sh

 

= Hi Jimmy and all,

=  

= I think Enke and Keyur's proposed text with help from Jakob makes the behav= ior simplified and deterministic to hold on BoRR till first EoR is seen.

=  

= IMHO it should be also spelled out what is the expected sequence error hand= ling here

 <= /p>

[Bruno] &#= 43;1.  And taking into account possible interaction with draft-ietf-id= r-bgp-gr-notification

 = ;

BTW:

“Whe= n the BGP speaker detects an error while processing a ROUTE-REFRESH message= with a non-zero "Message Subtype" field, it MUST send a NOTIFICA= TION message with Error Code "ROUTE-REFRESH Message Error".”

 = ;

Seems a pr= iori not inline with the recommendation from draft-ietf-grow-ops-reqs-for-b= gp-error-handling (which is to limit the consequences of error handling). Are we sure that no error condition could be handled in a more = friendly way? (e.g. if BoRR is not sent following a “normal route ref= resh request” or if 2 BoRR are sent consecutively…)<= /span>

 = ;

Thanks,

Regards,

Bruno=

 = ;

 = ;

... I think not following &= quot;MUST NOT" shall implicitly result in entire session drop and comp= lete restart ? Any error code ?

=  

= Best,
R.

=  

 

On Wed, Jan 29, 2014 at 9:22 AM, Dongjie (Jimmy) <= ;jie.dong@huawei.c= om> wrote:

Hi Robert,

 =

Agree that in these case= s the RRQ cannot be ignored, so postpone may be a better choice.

 =

While IMO stop the initi= al update and start over may delay the initial convergence, and as you said  it also relates to update group processing. What do = you think about the new text provided by Keyur?

 =

Best regards,

Jie

 =

From: rraszuk@gmail.com [mailto:rraszuk@gm= ail.com] On Behalf Of Robert Raszuk
Sent: Sunday, January 26, 2014 11:03 PM
To: Dongjie (Jimmy)
Cc: Keyur Patel (keyupate); Jakob Heitz; idr@ietf.org


Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refre= sh

 

Hi Jie,

 

I think it actually very easy to say that initial update can not ever guar= antee that RRQ received during its sending may meet the peer's need.

 

Example 1:

 

SAFI 128 - During receiving initial update from RR to PE new VRF got added= with new RT import. Unfortunately those updates received within initial update were already dropped as not interesting by the PE. R= R must resend full table after completed initial update. (Of course this is= the case where there is no RTC and that's why RTC helps a lot here by incr= emental nature). 

 

Example 2: 

 

SAFI 1 - Operator has modified inbound policy on EBGP peer during processi= ng of incoming updates and those originally were dropped. No soft reconfig in set. 

 

Conclusion:

 

RRQ can not ever be ignored. Sure they can be delayed or batched (case of = multiple peers within the same update/peer group) sending near RRQs (cluster of PEs got provisioned from central management = station). But as Keyur already mentioned those are rather standard local im= plementation optimizations. 

 

Question:

 

Does it maybe make sense to stop initial update when receiving RRQ from a = peer and start over ? Of course if peer is part of large update group it would have to be removed dynamically from it so othe= r members are not delayed. In any case I think this does not impact the spe= c but the implementation.

 

Cheers,
R.

 

 

 

On Sun, Jan 26, 2014 at 7:13 PM, Dongjie (Jim= my) <jie.dong@h= uawei.com> wrote:

Hi Keyur, Jakob,

Agree that "postpone" may be better. The point is we could avoid = the complicated cases/considerations of performing route refresh during ini= tial update:)

For "ignore", I was thinking of scenarios in which the route refr= esh requirement may already be met by the initial update, while I'd admit i= t is hard to say...



Best regards,
Jie

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

From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com]
Sent: Sunday, January 26, 2014 8:30 PM
To: Jakob Heitz; Dongjie (Jimmy)
Cc: idr@ietf.org
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Jie,

I agree with Jakob. You could make it *an implementation behavior* to postp= one the route refresh reply.


Regards,
Keyur

On 1/26/14 1:29 AM, "Jakob Heitz" <jakob.heitz@ericsson.com> wrote:<= br>
>You can definitely not ignore it, but you could postpone it.
>
>--
>Jakob Heitz.
>
>> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" <jie.dong@huawei.com>
>>wrote:
>>
>> After reading the analyses in this thread, my personal feeling is<= br> >>maybe we should avoid the interleaving between GR initial update an= d
>>route refresh/enhanced route refresh, since the initial update is j= ust
>>sending the whole Adj-RIB-Out, there is no obvious advantage to sta= rt
>>a route refresh/enhance route refresh during it. So a speaker shoul= d
>>ignore the RRQ received during the initial update. Thoughts?
>>
>> Best regards,
>> Jie
>>
>> -----Original Message-----
>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz
>> Sent: Saturday, January 25, 2014 10:48 PM
>> To: Chris Hall; = idr@ietf.org
>> Subject: Re: [Idr] WG LC for
>> draft-ietf-idr-bgp-enhanced-route-refresh
>>
>> RFCs are written for coders "practiced" in the art"= .
>> If anyone sends an EoRR before the adj-RIB-out is fully populated,=
>>then it's a BUG.
>> This does not need to be said.
>>
>> Personally, I believe a route refresh request should not be honore= d
>>until GR is complete.
>> Also, I don't believe a timer for the receipt of EoRR is necessary= ,
>>because the EoRR is guaranteed.
>> Guaranteed means "unless the session drops first".
>> --
>>
>> Jakob Heitz.
>>
>> ________________________________________
>> From: Chris Hall [chris.hall@highwayman.com]
>> Sent: Saturday, 25 January 2014 11:27 AM
>> To: idr@ietf.org=
>> Cc: Jakob Heitz
>> Subject: RE: [Idr] WG LC for
>> draft-ietf-idr-bgp-enhanced-route-refresh
>>
>> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37):
>> ...
>>> Silence means don't do it.
>>
>> Hmmm.... as a principle I'm more comfortable with "that which= isn't
>>prohibited is permitted"....
>>
>>> You would definitely NOT want BoRR to flush old stales.
>>
>> ....but, given the definite requirement, and given that the curren= t
>>precedent for "marking stale" does flush old stale, then = a few words
>>for the avoidance of doubt ?
>>
>>> Restarting the timer might be a good idea.
>>
>> I dunno... a route which remains stale for "a long time"= is, of
>>course, a candidate for being withdrawn: so having started a timer = the
>>first time things are set stale, I would avoid extending that -- at=
>>least for Graceful Restart, where the whole withdraw thing has been= "on-hold"
>>since the last session failed.  For route-refresh I guess ther= e's more
>>of a presumption that stale routes will be refreshed sooner or late= r,
>>and in the meantime they remain good.  So if the route-refresh= is
>>(repeatedly) restarted for some reason, perhaps it is more reasonab= le
>>to extend the flush deadline -- but avoid doing this indefinitely ?=
>>
>> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I ha= ve
>>built in Quagga prioritise route changes (pending changes and any t= hat
>>occur during the refresh) over refresh updates.  This makes it= more
>>likely that remaining stale routes are still good.  But the ot= her end
>>cannot know that.
>>
>> The paragraph in the draft discussing the "entire Adj-RIB-Out= "
>>defines that to be the entries present "at the start of the ro= ute
>>refresh operation", and observes that these comprise both reac= hable
>>and unreachable routes.  [An "of" after "compri= se" sets teeth on edge,
>>BTW.]  I'm really not sure what this paragraph is trying to te= ll me.
>> The reference to unreachable routes appears to suggest that pendin= g
>>withdraws should be sent as part of the refresh -- so not left to t= he
>>EoRR to implement at the end.  The point at which the EoRR is = sent is
>>defined such that it excludes any Adj-RIB-Out entries added after t= he
>>route-refresh started, but includes any which are changed during th= e
>>process.  It seems reasonable to delay any brand new reachable=
>>prefixes until after all previously announced ones have been refres= hed
>>and the EoRR sent -- if that's the intent here.  Changes which= occur
>>before the refresh gets to a given entry are pretty naturally swept= up
>>by the refresh.  Changes which occur after the refresh has gon= e past,
>>could/should be deferred to after the EoRR ?  Does it make a >>difference if the change is a withdraw ?  (Of course MRAI may = kick in here.  Ah.
>>MRAI and route-refresh, there's a topic !)
>>
>> I think the essence of the rule is that the EoRR should be sent on= ce
>>all prefixes previously advertised to the peer as reachable have be= en
>>refreshed, ie announced or withdrawn (at least) once.  Or, per= haps
>>more strictly, not *before* those prefixes have *all* been announce= d
>>once -- given that the EoRR will promptly bang un-advertised stuff = on the head.
>>Even more strictly perhaps: not send EoRR *before* any withdraws
>>implied by it are required or desirable.
>>
>> Depending on the implementation, a given sender may or may not be<= br> >>able to determine the minimum set of updates required before sendin= g EoRR.
>>
>> If the refresh operation takes a long time, there may be good
>>routeing reasons to arrange for some route changes to be sent to th= e peer "early"
>>-- that is to send announcements which do not contribute to the
>>refresh, but which are important enough to warrant delaying the end= of
>>the refresh.  That could be a matter for recommendation(s) in = the standard.
>>
>> NB: given that the timing of the EoRR is tied to the state of the<= br> >>Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. &= nbsp;At
>>the beginning of the initial update, the Restarting and Receiving >>speakers have:
>>
>>  Restarting:  Empty Adj-RIB-In   Empty Adj-RIB-Out<= br> >>
>>  Receiving:   Empty Adj-RIB-Out  Stale Adj-RIB-In >>
>> Now suppose (bonkers or otherwise) the receiving speaker sends an = RRQ
>>part way through the initial update.  The restarting speaker r= esponds
>>with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specifica= tion.
>> The receiving speaker sees the EoRR, and flushes stale.
>>Unfortunately, if the restarting speaker has not yet fully populate= d
>>its Adj-RIB-Out, then many further routes will be sent before the E= oR
>>falls due -- but the receiving speaker has already flushed their ti= ny
>>posteriors :-(
>>
>> I am coming to the view that route-refresh during a Graceful Resta= rt
>>initial update is a horse of a different colour altogether.
>>
>> [So the assumption that EoRR and EoR are triggered by the same thi= ng
>>was completely wrong, and I apologise for it.]
>>
>> Chris
>>
>> _______________________________________________
>> 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
htt= ps://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,
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 authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A070DFED8PEXCVZYM11corpo_-- From jakob.heitz@ericsson.com Wed Jan 29 07:17:56 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F671A0216 for ; Wed, 29 Jan 2014 07:17:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ej3lmslK_6Lc for ; Wed, 29 Jan 2014 07:17:52 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id B3BAD1A0349 for ; Wed, 29 Jan 2014 07:17:51 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-b5-52e91b9926af Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 75.9C.12743.99B19E25; Wed, 29 Jan 2014 16:17:45 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0387.000; Wed, 29 Jan 2014 10:17:07 -0500 From: Jakob Heitz To: "bruno.decraene@orange.com" Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPF5KdKHMolEg8TF26AxOKep0T6JqRMOhAgAGfMAD//7gu+4AAX1gA//+1BTCAAHhgAP//sQGgAA5+ToAABygAoAAmsOcAAAoIr7AAJlf4AP//r6/0gAEnPAD//8BcWoAA2iqAgAAMEwCAAB6LgIAD81WAgAAOsoCAAAoOAIAAB0uL Date: Wed, 29 Jan 2014 15:17:06 +0000 Message-ID: <0C0CE57B-CA57-471D-BE3C-8B5F380BE087@ericsson.com> References: <00AB3F7F-5E33-4533-96C7-E7F75A3E76CB@ericsson.com> <76CD132C3ADEF848BD84D028D243C927335C435C@nkgeml512-mbx.china.huawei.com> <76CD132C3ADEF848BD84D028D243C927335C6B18@nkgeml512-mbx.china.huawei.com> , <6650_1390989061_52E8CF05_6650_399_1_53C29892C857584299CBF5D05346208A070DFED8@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <6650_1390989061_52E8CF05_6650_399_1_53C29892C857584299CBF5D05346208A070DFED8@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_0C0CE57BCA57471DBE3C8B5F380BE087ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyuXRPoO5M6ZdBBl2H9S1+7JjDbPHq9jMm i8at59ksmhY2MTuweEz5vZHVY8mSn0weLc9Osnns3riAKYAlissmJTUnsyy1SN8ugSvj/AXO gs8vmCp+dfg1MO7ewdTFyMkhIWAicfTCDDYIW0ziwr31QDYXh5DAEUaJmzunMEE4yxklbm9Z xQJSxSagI/HtehcziC0iYC3xYCJIBwcHs0CpxIR3MSBhYQE3iVeTlrNDlLhLtPyYxAwyR0Rg H6PEg+UtYNtYBFQl9t2fzwzSyytgL3F0gjjErhYWie5ZR9lBHE6BVkaJD41LwZYxAp33/dQa sLOZBcQlbj2ZD/WCgMSSPeeZIWxRiZeP/7FC1CRL7L3UxAhi8woISpyc+YRlAqPILCTts5CU zUJSBhE3kHh/bj4zhK0tsWzhayhbX2Ljl7OMyOILGNlXMXKUFqeW5aYbGWxiBEbaMQk23R2M e15aHmKU5mBREuf98tY5SEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVANj1Hy+E5q3f82sepxQ tJyRo6j3+n1J2323hSVb1U4KnU/P6FMyXsjd66qqsZOp+mEpx4m6/JoXHC3lyYFyR7JWva25 kpAR9eOV4A/LRiue3bem2ardT1d4oyv0+DVjwNTVp6tfGkpwhvvMmxOuxsF53dAlW+TtM6Fs LrYtsubvO2zMr7+W3q7EUpyRaKjFXFScCAANCW44ggIAAA== Cc: "Keyur Patel \(keyupate\)" , "idr@ietf.org" , Robert Raszuk Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 15:17:57 -0000 --_000_0C0CE57BCA57471DBE3C8B5F380BE087ericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I don't think these minor errors are worth killing a session (and all the o= ther routes) for. Get a BoRR, mark stale. Get an EoRR or EoR, delete stale. If you get two BoRR in a row, it just means the sender decided to abort a r= efresh and start a new one. If in doubt, send another refresh request. You'll get another BoRR in respo= nse, so don't overdo it. -- Jakob Heitz. On Jan 29, 2014, at 1:51 AM, "bruno.decraene@orange.com" > wrote: Hi all, From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: Wednesday, January 29, 2014 10:15 AM To: Dongjie (Jimmy) Cc: Keyur Patel (keyupate); idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Jimmy and all, I think Enke and Keyur's proposed text with help from Jakob makes the behav= ior simplified and deterministic to hold on BoRR till first EoR is seen. IMHO it should be also spelled out what is the expected sequence error hand= ling here [Bruno] +1. And taking into account possible interaction with draft-ietf-i= dr-bgp-gr-notification BTW: =93When the BGP speaker detects an error while processing a ROUTE-REFRESH m= essage with a non-zero "Message Subtype" field, it MUST send a NOTIFICATION= message with Error Code "ROUTE-REFRESH Message Error".=94 Seems a priori not inline with the recommendation from draft-ietf-grow-ops-= reqs-for-bgp-error-handling (which is to limit the consequences of error ha= ndling). Are we sure that no error condition could be handled in a more fri= endly way? (e.g. if BoRR is not sent following a =93normal route refresh re= quest=94 or if 2 BoRR are sent consecutively=85) Thanks, Regards, Bruno ... I think not following "MUST NOT" shall implicitly result in entire sess= ion drop and complete restart ? Any error code ? Best, R. On Wed, Jan 29, 2014 at 9:22 AM, Dongjie (Jimmy) > wrote: Hi Robert, Agree that in these cases the RRQ cannot be ignored, so postpone may be a b= etter choice. While IMO stop the initial update and start over may delay the initial conv= ergence, and as you said it also relates to update group processing. What = do you think about the new text provided by Keyur? Best regards, Jie From: rraszuk@gmail.com [mailto:rraszuk@gmail.com= ] On Behalf Of Robert Raszuk Sent: Sunday, January 26, 2014 11:03 PM To: Dongjie (Jimmy) Cc: Keyur Patel (keyupate); Jakob Heitz; idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Jie, I think it actually very easy to say that initial update can not ever guara= ntee that RRQ received during its sending may meet the peer's need. Example 1: SAFI 128 - During receiving initial update from RR to PE new VRF got added = with new RT import. Unfortunately those updates received within initial upd= ate were already dropped as not interesting by the PE. RR must resend full = table after completed initial update. (Of course this is the case where the= re is no RTC and that's why RTC helps a lot here by incremental nature). Example 2: SAFI 1 - Operator has modified inbound policy on EBGP peer during processin= g of incoming updates and those originally were dropped. No soft reconfig i= n set. Conclusion: RRQ can not ever be ignored. Sure they can be delayed or batched (case of m= ultiple peers within the same update/peer group) sending near RRQs (cluster= of PEs got provisioned from central management station). But as Keyur alre= ady mentioned those are rather standard local implementation optimizations. Question: Does it maybe make sense to stop initial update when receiving RRQ from a p= eer and start over ? Of course if peer is part of large update group it wou= ld have to be removed dynamically from it so other members are not delayed.= In any case I think this does not impact the spec but the implementation. Cheers, R. On Sun, Jan 26, 2014 at 7:13 PM, Dongjie (Jimmy) > wrote: Hi Keyur, Jakob, Agree that "postpone" may be better. The point is we could avoid the compli= cated cases/considerations of performing route refresh during initial updat= e:) For "ignore", I was thinking of scenarios in which the route refresh requir= ement may already be met by the initial update, while I'd admit it is hard = to say... Best regards, Jie -----Original Message----- From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] Sent: Sunday, January 26, 2014 8:30 PM To: Jakob Heitz; Dongjie (Jimmy) Cc: idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Jie, I agree with Jakob. You could make it *an implementation behavior* to postp= one the route refresh reply. Regards, Keyur On 1/26/14 1:29 AM, "Jakob Heitz" > wrote: >You can definitely not ignore it, but you could postpone it. > >-- >Jakob Heitz. > >> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" > >>wrote: >> >> After reading the analyses in this thread, my personal feeling is >>maybe we should avoid the interleaving between GR initial update and >>route refresh/enhanced route refresh, since the initial update is just >>sending the whole Adj-RIB-Out, there is no obvious advantage to start >>a route refresh/enhance route refresh during it. So a speaker should >>ignore the RRQ received during the initial update. Thoughts? >> >> Best regards, >> Jie >> >> -----Original Message----- >> From: Idr [mailto:idr-bounces@ietf.org] On = Behalf Of Jakob Heitz >> Sent: Saturday, January 25, 2014 10:48 PM >> To: Chris Hall; idr@ietf.org >> Subject: Re: [Idr] WG LC for >> draft-ietf-idr-bgp-enhanced-route-refresh >> >> RFCs are written for coders "practiced" in the art". >> If anyone sends an EoRR before the adj-RIB-out is fully populated, >>then it's a BUG. >> This does not need to be said. >> >> Personally, I believe a route refresh request should not be honored >>until GR is complete. >> Also, I don't believe a timer for the receipt of EoRR is necessary, >>because the EoRR is guaranteed. >> Guaranteed means "unless the session drops first". >> -- >> >> Jakob Heitz. >> >> ________________________________________ >> From: Chris Hall [chris.hall@highwayman.com] >> Sent: Saturday, 25 January 2014 11:27 AM >> To: idr@ietf.org >> Cc: Jakob Heitz >> Subject: RE: [Idr] WG LC for >> draft-ietf-idr-bgp-enhanced-route-refresh >> >> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): >> ... >>> Silence means don't do it. >> >> Hmmm.... as a principle I'm more comfortable with "that which isn't >>prohibited is permitted".... >> >>> You would definitely NOT want BoRR to flush old stales. >> >> ....but, given the definite requirement, and given that the current >>precedent for "marking stale" does flush old stale, then a few words >>for the avoidance of doubt ? >> >>> Restarting the timer might be a good idea. >> >> I dunno... a route which remains stale for "a long time" is, of >>course, a candidate for being withdrawn: so having started a timer the >>first time things are set stale, I would avoid extending that -- at >>least for Graceful Restart, where the whole withdraw thing has been "on-h= old" >>since the last session failed. For route-refresh I guess there's more >>of a presumption that stale routes will be refreshed sooner or later, >>and in the meantime they remain good. So if the route-refresh is >>(repeatedly) restarted for some reason, perhaps it is more reasonable >>to extend the flush deadline -- but avoid doing this indefinitely ? >> >> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I have >>built in Quagga prioritise route changes (pending changes and any that >>occur during the refresh) over refresh updates. This makes it more >>likely that remaining stale routes are still good. But the other end >>cannot know that. >> >> The paragraph in the draft discussing the "entire Adj-RIB-Out" >>defines that to be the entries present "at the start of the route >>refresh operation", and observes that these comprise both reachable >>and unreachable routes. [An "of" after "comprise" sets teeth on edge, >>BTW.] I'm really not sure what this paragraph is trying to tell me. >> The reference to unreachable routes appears to suggest that pending >>withdraws should be sent as part of the refresh -- so not left to the >>EoRR to implement at the end. The point at which the EoRR is sent is >>defined such that it excludes any Adj-RIB-Out entries added after the >>route-refresh started, but includes any which are changed during the >>process. It seems reasonable to delay any brand new reachable >>prefixes until after all previously announced ones have been refreshed >>and the EoRR sent -- if that's the intent here. Changes which occur >>before the refresh gets to a given entry are pretty naturally swept up >>by the refresh. Changes which occur after the refresh has gone past, >>could/should be deferred to after the EoRR ? Does it make a >>difference if the change is a withdraw ? (Of course MRAI may kick in her= e. Ah. >>MRAI and route-refresh, there's a topic !) >> >> I think the essence of the rule is that the EoRR should be sent once >>all prefixes previously advertised to the peer as reachable have been >>refreshed, ie announced or withdrawn (at least) once. Or, perhaps >>more strictly, not *before* those prefixes have *all* been announced >>once -- given that the EoRR will promptly bang un-advertised stuff on the= head. >>Even more strictly perhaps: not send EoRR *before* any withdraws >>implied by it are required or desirable. >> >> Depending on the implementation, a given sender may or may not be >>able to determine the minimum set of updates required before sending EoRR= . >> >> If the refresh operation takes a long time, there may be good >>routeing reasons to arrange for some route changes to be sent to the peer= "early" >>-- that is to send announcements which do not contribute to the >>refresh, but which are important enough to warrant delaying the end of >>the refresh. That could be a matter for recommendation(s) in the standar= d. >> >> NB: given that the timing of the EoRR is tied to the state of the >>Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. At >>the beginning of the initial update, the Restarting and Receiving >>speakers have: >> >> Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out >> >> Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In >> >> Now suppose (bonkers or otherwise) the receiving speaker sends an RRQ >>part way through the initial update. The restarting speaker responds >>with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specification. >> The receiving speaker sees the EoRR, and flushes stale. >>Unfortunately, if the restarting speaker has not yet fully populated >>its Adj-RIB-Out, then many further routes will be sent before the EoR >>falls due -- but the receiving speaker has already flushed their tiny >>posteriors :-( >> >> I am coming to the view that route-refresh during a Graceful Restart >>initial update is a horse of a different colour altogether. >> >> [So the assumption that EoRR and EoR are triggered by the same thing >>was completely wrong, and I apologise for it.] >> >> Chris >> >> _______________________________________________ >> 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 ___________________________________________________________________________= ______________________________________________ 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, 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 authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_0C0CE57BCA57471DBE3C8B5F380BE087ericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I don't think these minor errors are worth killing a session (and all = the other routes) for.
Get a BoRR, mark stale.
Get an EoRR or EoR, delete stale.
If you get two BoRR in a row, it just means the sender decided to abor= t a refresh and start a new one.
If in doubt, send another refresh request. You'll get another BoRR in = response, so don't overdo it.

--
Jakob Heitz.


On Jan 29, 2014, at 1:51 AM, "bruno.decraene@orange.com" <bruno.decraene@orange.com> wrote:

Hi all,=

 <= /p>

 <= /p>

From: Idr [mailto:i= dr-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Wednesday, January 29, 2014 10:15 AM
To: Dongjie (Jimmy)
Cc: Keyur Patel (keyupate); idr@ietf= .org
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refre= sh

 

= Hi Jimmy and all,

=  

= I think Enke and Keyur's proposed text with help from Jakob makes the behav= ior simplified and deterministic to hold on BoRR till first EoR is seen.

=  

= IMHO it should be also spelled out what is the expected sequence error hand= ling here

 <= /p>

[Bruno] &#= 43;1.  And taking into account possible interaction with draft-ietf-id= r-bgp-gr-notification

 = ;

BTW:

=93When th= e BGP speaker detects an error while processing a ROUTE-REFRESH message wit= h a non-zero "Message Subtype" field, it MUST send a NOTIFICATION message with Error Code "ROUTE-REFRESH Message Error".=94

 = ;

Seems a pr= iori not inline with the recommendation from draft-ietf-grow-ops-reqs-for-b= gp-error-handling (which is to limit the consequences of error handling). Are we sure that no error condition could be handled in a more = friendly way? (e.g. if BoRR is not sent following a =93normal route refresh= request=94 or if 2 BoRR are sent consecutively=85)

 = ;

Thanks,

Regards,

Bruno=

 = ;

 = ;

... I think not following &= quot;MUST NOT" shall implicitly result in entire session drop and comp= lete restart ? Any error code ?

=  

= Best,
R.

=  

 

On Wed, Jan 29, 2014 at 9:22 AM, Dongjie (Jimmy) <= ;jie.dong@huawei.c= om> wrote:

Hi Robert,

 =

Agree that in these case= s the RRQ cannot be ignored, so postpone may be a better choice.

 =

While IMO stop the initi= al update and start over may delay the initial convergence, and as you said  it also relates to update group processing. What do = you think about the new text provided by Keyur?

 =

Best regards,

Jie

 =

From: rraszuk@gmail.com [mailto:rraszuk@gm= ail.com] On Behalf Of Robert Raszuk
Sent: Sunday, January 26, 2014 11:03 PM
To: Dongjie (Jimmy)
Cc: Keyur Patel (keyupate); Jakob Heitz; idr@ietf.org


Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refre= sh

 

Hi Jie,

 

I think it actually very easy to say that initial update can not ever guar= antee that RRQ received during its sending may meet the peer's need.

 

Example 1:

 

SAFI 128 - During receiving initial update from RR to PE new VRF got added= with new RT import. Unfortunately those updates received within initial update were already dropped as not interesting by the PE. R= R must resend full table after completed initial update. (Of course this is= the case where there is no RTC and that's why RTC helps a lot here by incr= emental nature). 

 

Example 2: 

 

SAFI 1 - Operator has modified inbound policy on EBGP peer during processi= ng of incoming updates and those originally were dropped. No soft reconfig in set. 

 

Conclusion:

 

RRQ can not ever be ignored. Sure they can be delayed or batched (case of = multiple peers within the same update/peer group) sending near RRQs (cluster of PEs got provisioned from central management = station). But as Keyur already mentioned those are rather standard local im= plementation optimizations. 

 

Question:

 

Does it maybe make sense to stop initial update when receiving RRQ from a = peer and start over ? Of course if peer is part of large update group it would have to be removed dynamically from it so othe= r members are not delayed. In any case I think this does not impact the spe= c but the implementation.

 

Cheers,
R.

 

 

 

On Sun, Jan 26, 2014 at 7:13 PM, Dongjie (Jim= my) <jie.dong@h= uawei.com> wrote:

Hi Keyur, Jakob,

Agree that "postpone" may be better. The point is we could avoid = the complicated cases/considerations of performing route refresh during ini= tial update:)

For "ignore", I was thinking of scenarios in which the route refr= esh requirement may already be met by the initial update, while I'd admit i= t is hard to say...



Best regards,
Jie

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

From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] Sent: Sunday, January 26, 2014 8:30 PM
To: Jakob Heitz; Dongjie (Jimmy)
Cc: idr@ietf.org
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Jie,

I agree with Jakob. You could make it *an implementation behavior* to postp= one the route refresh reply.


Regards,
Keyur

On 1/26/14 1:29 AM, "Jakob Heitz" <jakob.heitz@ericsson.com> wrote:<= br>
>You can definitely not ignore it, but you could postpone it.
>
>--
>Jakob Heitz.
>
>> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" <jie.dong@huawei.com>
>>wrote:
>>
>> After reading the analyses in this thread, my personal feeling is<= br> >>maybe we should avoid the interleaving between GR initial update an= d
>>route refresh/enhanced route refresh, since the initial update is j= ust
>>sending the whole Adj-RIB-Out, there is no obvious advantage to sta= rt
>>a route refresh/enhance route refresh during it. So a speaker shoul= d
>>ignore the RRQ received during the initial update. Thoughts?
>>
>> Best regards,
>> Jie
>>
>> -----Original Message-----
>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz
>> Sent: Saturday, January 25, 2014 10:48 PM
>> To: Chris Hall; = idr@ietf.org
>> Subject: Re: [Idr] WG LC for
>> draft-ietf-idr-bgp-enhanced-route-refresh
>>
>> RFCs are written for coders "practiced" in the art"= .
>> If anyone sends an EoRR before the adj-RIB-out is fully populated,=
>>then it's a BUG.
>> This does not need to be said.
>>
>> Personally, I believe a route refresh request should not be honore= d
>>until GR is complete.
>> Also, I don't believe a timer for the receipt of EoRR is necessary= ,
>>because the EoRR is guaranteed.
>> Guaranteed means "unless the session drops first".
>> --
>>
>> Jakob Heitz.
>>
>> ________________________________________
>> From: Chris Hall [chris.hall@highwayman.com]
>> Sent: Saturday, 25 January 2014 11:27 AM
>> To: idr@ietf.org=
>> Cc: Jakob Heitz
>> Subject: RE: [Idr] WG LC for
>> draft-ietf-idr-bgp-enhanced-route-refresh
>>
>> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37):
>> ...
>>> Silence means don't do it.
>>
>> Hmmm.... as a principle I'm more comfortable with "that which= isn't
>>prohibited is permitted"....
>>
>>> You would definitely NOT want BoRR to flush old stales.
>>
>> ....but, given the definite requirement, and given that the curren= t
>>precedent for "marking stale" does flush old stale, then = a few words
>>for the avoidance of doubt ?
>>
>>> Restarting the timer might be a good idea.
>>
>> I dunno... a route which remains stale for "a long time"= is, of
>>course, a candidate for being withdrawn: so having started a timer = the
>>first time things are set stale, I would avoid extending that -- at=
>>least for Graceful Restart, where the whole withdraw thing has been= "on-hold"
>>since the last session failed.  For route-refresh I guess ther= e's more
>>of a presumption that stale routes will be refreshed sooner or late= r,
>>and in the meantime they remain good.  So if the route-refresh= is
>>(repeatedly) restarted for some reason, perhaps it is more reasonab= le
>>to extend the flush deadline -- but avoid doing this indefinitely ?=
>>
>> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I ha= ve
>>built in Quagga prioritise route changes (pending changes and any t= hat
>>occur during the refresh) over refresh updates.  This makes it= more
>>likely that remaining stale routes are still good.  But the ot= her end
>>cannot know that.
>>
>> The paragraph in the draft discussing the "entire Adj-RIB-Out= "
>>defines that to be the entries present "at the start of the ro= ute
>>refresh operation", and observes that these comprise both reac= hable
>>and unreachable routes.  [An "of" after "compri= se" sets teeth on edge,
>>BTW.]  I'm really not sure what this paragraph is trying to te= ll me.
>> The reference to unreachable routes appears to suggest that pendin= g
>>withdraws should be sent as part of the refresh -- so not left to t= he
>>EoRR to implement at the end.  The point at which the EoRR is = sent is
>>defined such that it excludes any Adj-RIB-Out entries added after t= he
>>route-refresh started, but includes any which are changed during th= e
>>process.  It seems reasonable to delay any brand new reachable=
>>prefixes until after all previously announced ones have been refres= hed
>>and the EoRR sent -- if that's the intent here.  Changes which= occur
>>before the refresh gets to a given entry are pretty naturally swept= up
>>by the refresh.  Changes which occur after the refresh has gon= e past,
>>could/should be deferred to after the EoRR ?  Does it make a >>difference if the change is a withdraw ?  (Of course MRAI may = kick in here.  Ah.
>>MRAI and route-refresh, there's a topic !)
>>
>> I think the essence of the rule is that the EoRR should be sent on= ce
>>all prefixes previously advertised to the peer as reachable have be= en
>>refreshed, ie announced or withdrawn (at least) once.  Or, per= haps
>>more strictly, not *before* those prefixes have *all* been announce= d
>>once -- given that the EoRR will promptly bang un-advertised stuff = on the head.
>>Even more strictly perhaps: not send EoRR *before* any withdraws >>implied by it are required or desirable.
>>
>> Depending on the implementation, a given sender may or may not be<= br> >>able to determine the minimum set of updates required before sendin= g EoRR.
>>
>> If the refresh operation takes a long time, there may be good
>>routeing reasons to arrange for some route changes to be sent to th= e peer "early"
>>-- that is to send announcements which do not contribute to the
>>refresh, but which are important enough to warrant delaying the end= of
>>the refresh.  That could be a matter for recommendation(s) in = the standard.
>>
>> NB: given that the timing of the EoRR is tied to the state of the<= br> >>Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. &= nbsp;At
>>the beginning of the initial update, the Restarting and Receiving >>speakers have:
>>
>>  Restarting:  Empty Adj-RIB-In   Empty Adj-RIB-Out<= br> >>
>>  Receiving:   Empty Adj-RIB-Out  Stale Adj-RIB-In >>
>> Now suppose (bonkers or otherwise) the receiving speaker sends an = RRQ
>>part way through the initial update.  The restarting speaker r= esponds
>>with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specifica= tion.
>> The receiving speaker sees the EoRR, and flushes stale.
>>Unfortunately, if the restarting speaker has not yet fully populate= d
>>its Adj-RIB-Out, then many further routes will be sent before the E= oR
>>falls due -- but the receiving speaker has already flushed their ti= ny
>>posteriors :-(
>>
>> I am coming to the view that route-refresh during a Graceful Resta= rt
>>initial update is a horse of a different colour altogether.
>>
>> [So the assumption that EoRR and EoR are triggered by the same thi= ng
>>was completely wrong, and I apologise for it.]
>>
>> Chris
>>
>> _______________________________________________
>> 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
htt= ps://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,
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 authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.iet= f.org/mailman/listinfo/idr
--_000_0C0CE57BCA57471DBE3C8B5F380BE087ericssoncom_-- From rraszuk@gmail.com Wed Jan 29 07:32:01 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC6C11A03CD for ; Wed, 29 Jan 2014 07:32:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPYLnJB7lFaA for ; Wed, 29 Jan 2014 07:31:55 -0800 (PST) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1351A0218 for ; Wed, 29 Jan 2014 07:31:54 -0800 (PST) Received: by mail-ig0-f170.google.com with SMTP id m12so17529557iga.1 for ; Wed, 29 Jan 2014 07:31:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ILIkUbTI8q4D8cqGo5d9FeTehmT4Q4RNUEKgzOl6rRs=; b=XQRKXtQpdKuoUGv1d99+dvVJDr9V7SMTobi4k4P7XEPcAud2RVa3tXL+uLUAkIPDZG +K9AQXnVLERcKNg4IPvoj1AoAc3EsR34arbdcCt5IY3KswrgfA0tEaawlKXQSpgnSc5l p6H/KfiRIK3ql/SOzdh57B7dF9sbkzNhU/sRdWvXJBcoZQoMlPohV8pfmbuhEoGt+yvC toLIx8ePTRL4XfNFPTh5BlsNGb7MKxIlrfWSdB/FhqxXrxUcTh7e1Wg5s2v77uSzSM+w DtXyKCeHKvmLeKff1dBPZovbF0GXOifUb2s9u1K66quB0TJzo+jDQ5VoqothmZoAlv9c MiQA== MIME-Version: 1.0 X-Received: by 10.50.87.201 with SMTP id ba9mr8906524igb.21.1391009511952; Wed, 29 Jan 2014 07:31:51 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.212.8 with HTTP; Wed, 29 Jan 2014 07:31:51 -0800 (PST) In-Reply-To: <0C0CE57B-CA57-471D-BE3C-8B5F380BE087@ericsson.com> References: <00AB3F7F-5E33-4533-96C7-E7F75A3E76CB@ericsson.com> <76CD132C3ADEF848BD84D028D243C927335C435C@nkgeml512-mbx.china.huawei.com> <76CD132C3ADEF848BD84D028D243C927335C6B18@nkgeml512-mbx.china.huawei.com> <6650_1390989061_52E8CF05_6650_399_1_53C29892C857584299CBF5D05346208A070DFED8@PEXCVZYM11.corporate.adroot.infra.ftgroup> <0C0CE57B-CA57-471D-BE3C-8B5F380BE087@ericsson.com> Date: Wed, 29 Jan 2014 16:31:51 +0100 X-Google-Sender-Auth: eVtiWT2LG4x8PlUl8g7eOy2wLUA Message-ID: From: Robert Raszuk To: Jakob Heitz Content-Type: multipart/alternative; boundary=e89a8f3ba17dd6d96404f11da310 Cc: "Keyur Patel \(keyupate\)" , "bruno.decraene@orange.com" , "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 15:32:01 -0000 --e89a8f3ba17dd6d96404f11da310 Content-Type: text/plain; charset=ISO-8859-1 Hi Jakob, I thought we are mostly talking about initial time period after the session is established and peer did not send EOR yet. So perhaps session reset with right error is not that bad thing to do - if for nothing else then to signal to the peer that his sequence is wrong ? Or maybe we should do such things in BGP Diagnostic Message ? Best, R. On Wed, Jan 29, 2014 at 4:17 PM, Jakob Heitz wrote: > I don't think these minor errors are worth killing a session (and all > the other routes) for. > Get a BoRR, mark stale. > Get an EoRR or EoR, delete stale. > If you get two BoRR in a row, it just means the sender decided to abort a > refresh and start a new one. > If in doubt, send another refresh request. You'll get another BoRR in > response, so don't overdo it. > > -- > Jakob Heitz. > > > On Jan 29, 2014, at 1:51 AM, "bruno.decraene@orange.com" < > bruno.decraene@orange.com> wrote: > > Hi all, > > > > > > *From:* Idr [mailto:idr-bounces@ietf.org ] *On > Behalf Of *Robert Raszuk > *Sent:* Wednesday, January 29, 2014 10:15 AM > *To:* Dongjie (Jimmy) > *Cc:* Keyur Patel (keyupate); idr@ietf.org > *Subject:* Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh > > > > Hi Jimmy and all, > > > > I think Enke and Keyur's proposed text with help from Jakob makes the > behavior simplified and deterministic to hold on BoRR till first EoR is > seen. > > > > IMHO it should be also spelled out what is the expected sequence error > handling here > > > > [Bruno] +1. And taking into account possible interaction with > draft-ietf-idr-bgp-gr-notification > > > > BTW: > > "When the BGP speaker detects an error while processing a ROUTE-REFRESH > message with a non-zero "Message Subtype" field, it MUST send a > NOTIFICATION message with Error Code "ROUTE-REFRESH Message Error"." > > > > Seems a priori not inline with the recommendation from > draft-ietf-grow-ops-reqs-for-bgp-error-handling (which is to limit the > consequences of error handling). Are we sure that no error condition could > be handled in a more friendly way? (e.g. if BoRR is not sent following a > "normal route refresh request" or if 2 BoRR are sent consecutively...) > > > > Thanks, > > Regards, > > Bruno > > > > > > ... I think not following "MUST NOT" shall implicitly result in entire > session drop and complete restart ? Any error code ? > > > > Best, > R. > > > > > > On Wed, Jan 29, 2014 at 9:22 AM, Dongjie (Jimmy) > wrote: > > Hi Robert, > > > > Agree that in these cases the RRQ cannot be ignored, so postpone may be a > better choice. > > > > While IMO stop the initial update and start over may delay the initial > convergence, and as you said it also relates to update group processing. > What do you think about the new text provided by Keyur? > > > > Best regards, > > Jie > > > > *From:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Robert > Raszuk > *Sent:* Sunday, January 26, 2014 11:03 PM > *To:* Dongjie (Jimmy) > *Cc:* Keyur Patel (keyupate); Jakob Heitz; idr@ietf.org > > > *Subject:* Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh > > > > Hi Jie, > > > > I think it actually very easy to say that initial update can not ever > guarantee that RRQ received during its sending may meet the peer's need. > > > > Example 1: > > > > SAFI 128 - During receiving initial update from RR to PE new VRF got added > with new RT import. Unfortunately those updates received within initial > update were already dropped as not interesting by the PE. RR must resend > full table after completed initial update. (Of course this is the case > where there is no RTC and that's why RTC helps a lot here by incremental > nature). > > > > Example 2: > > > > SAFI 1 - Operator has modified inbound policy on EBGP peer during > processing of incoming updates and those originally were dropped. No soft > reconfig in set. > > > > Conclusion: > > > > RRQ can not ever be ignored. Sure they can be delayed or batched (case of > multiple peers within the same update/peer group) sending near RRQs > (cluster of PEs got provisioned from central management station). But as > Keyur already mentioned those are rather standard local implementation > optimizations. > > > > Question: > > > > Does it maybe make sense to stop initial update when receiving RRQ from a > peer and start over ? Of course if peer is part of large update group it > would have to be removed dynamically from it so other members are not > delayed. In any case I think this does not impact the spec but the > implementation. > > > > Cheers, > R. > > > > > > > > On Sun, Jan 26, 2014 at 7:13 PM, Dongjie (Jimmy) > wrote: > > Hi Keyur, Jakob, > > Agree that "postpone" may be better. The point is we could avoid the > complicated cases/considerations of performing route refresh during initial > update:) > > For "ignore", I was thinking of scenarios in which the route refresh > requirement may already be met by the initial update, while I'd admit it is > hard to say... > > > > Best regards, > Jie > > -----Original Message----- > > From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] > Sent: Sunday, January 26, 2014 8:30 PM > To: Jakob Heitz; Dongjie (Jimmy) > Cc: idr@ietf.org > Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh > > Jie, > > I agree with Jakob. You could make it *an implementation behavior* to > postpone the route refresh reply. > > > Regards, > Keyur > > On 1/26/14 1:29 AM, "Jakob Heitz" wrote: > > >You can definitely not ignore it, but you could postpone it. > > > >-- > >Jakob Heitz. > > > >> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" > >>wrote: > >> > >> After reading the analyses in this thread, my personal feeling is > >>maybe we should avoid the interleaving between GR initial update and > >>route refresh/enhanced route refresh, since the initial update is just > >>sending the whole Adj-RIB-Out, there is no obvious advantage to start > >>a route refresh/enhance route refresh during it. So a speaker should > >>ignore the RRQ received during the initial update. Thoughts? > >> > >> Best regards, > >> Jie > >> > >> -----Original Message----- > >> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz > >> Sent: Saturday, January 25, 2014 10:48 PM > >> To: Chris Hall; idr@ietf.org > >> Subject: Re: [Idr] WG LC for > >> draft-ietf-idr-bgp-enhanced-route-refresh > >> > >> RFCs are written for coders "practiced" in the art". > >> If anyone sends an EoRR before the adj-RIB-out is fully populated, > >>then it's a BUG. > >> This does not need to be said. > >> > >> Personally, I believe a route refresh request should not be honored > >>until GR is complete. > >> Also, I don't believe a timer for the receipt of EoRR is necessary, > >>because the EoRR is guaranteed. > >> Guaranteed means "unless the session drops first". > >> -- > >> > >> Jakob Heitz. > >> > >> ________________________________________ > >> From: Chris Hall [chris.hall@highwayman.com] > >> Sent: Saturday, 25 January 2014 11:27 AM > >> To: idr@ietf.org > >> Cc: Jakob Heitz > >> Subject: RE: [Idr] WG LC for > >> draft-ietf-idr-bgp-enhanced-route-refresh > >> > >> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): > >> ... > >>> Silence means don't do it. > >> > >> Hmmm.... as a principle I'm more comfortable with "that which isn't > >>prohibited is permitted".... > >> > >>> You would definitely NOT want BoRR to flush old stales. > >> > >> ....but, given the definite requirement, and given that the current > >>precedent for "marking stale" does flush old stale, then a few words > >>for the avoidance of doubt ? > >> > >>> Restarting the timer might be a good idea. > >> > >> I dunno... a route which remains stale for "a long time" is, of > >>course, a candidate for being withdrawn: so having started a timer the > >>first time things are set stale, I would avoid extending that -- at > >>least for Graceful Restart, where the whole withdraw thing has been > "on-hold" > >>since the last session failed. For route-refresh I guess there's more > >>of a presumption that stale routes will be refreshed sooner or later, > >>and in the meantime they remain good. So if the route-refresh is > >>(repeatedly) restarted for some reason, perhaps it is more reasonable > >>to extend the flush deadline -- but avoid doing this indefinitely ? > >> > >> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I have > >>built in Quagga prioritise route changes (pending changes and any that > >>occur during the refresh) over refresh updates. This makes it more > >>likely that remaining stale routes are still good. But the other end > >>cannot know that. > >> > >> The paragraph in the draft discussing the "entire Adj-RIB-Out" > >>defines that to be the entries present "at the start of the route > >>refresh operation", and observes that these comprise both reachable > >>and unreachable routes. [An "of" after "comprise" sets teeth on edge, > >>BTW.] I'm really not sure what this paragraph is trying to tell me. > >> The reference to unreachable routes appears to suggest that pending > >>withdraws should be sent as part of the refresh -- so not left to the > >>EoRR to implement at the end. The point at which the EoRR is sent is > >>defined such that it excludes any Adj-RIB-Out entries added after the > >>route-refresh started, but includes any which are changed during the > >>process. It seems reasonable to delay any brand new reachable > >>prefixes until after all previously announced ones have been refreshed > >>and the EoRR sent -- if that's the intent here. Changes which occur > >>before the refresh gets to a given entry are pretty naturally swept up > >>by the refresh. Changes which occur after the refresh has gone past, > >>could/should be deferred to after the EoRR ? Does it make a > >>difference if the change is a withdraw ? (Of course MRAI may kick in > here. Ah. > >>MRAI and route-refresh, there's a topic !) > >> > >> I think the essence of the rule is that the EoRR should be sent once > >>all prefixes previously advertised to the peer as reachable have been > >>refreshed, ie announced or withdrawn (at least) once. Or, perhaps > >>more strictly, not *before* those prefixes have *all* been announced > >>once -- given that the EoRR will promptly bang un-advertised stuff on > the head. > >>Even more strictly perhaps: not send EoRR *before* any withdraws > >>implied by it are required or desirable. > >> > >> Depending on the implementation, a given sender may or may not be > >>able to determine the minimum set of updates required before sending > EoRR. > >> > >> If the refresh operation takes a long time, there may be good > >>routeing reasons to arrange for some route changes to be sent to the > peer "early" > >>-- that is to send announcements which do not contribute to the > >>refresh, but which are important enough to warrant delaying the end of > >>the refresh. That could be a matter for recommendation(s) in the > standard. > >> > >> NB: given that the timing of the EoRR is tied to the state of the > >>Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. At > >>the beginning of the initial update, the Restarting and Receiving > >>speakers have: > >> > >> Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out > >> > >> Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In > >> > >> Now suppose (bonkers or otherwise) the receiving speaker sends an RRQ > >>part way through the initial update. The restarting speaker responds > >>with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specification. > >> The receiving speaker sees the EoRR, and flushes stale. > >>Unfortunately, if the restarting speaker has not yet fully populated > >>its Adj-RIB-Out, then many further routes will be sent before the EoR > >>falls due -- but the receiving speaker has already flushed their tiny > >>posteriors :-( > >> > >> I am coming to the view that route-refresh during a Graceful Restart > >>initial update is a horse of a different colour altogether. > >> > >> [So the assumption that EoRR and EoR are triggered by the same thing > >>was completely wrong, and I apologise for it.] > >> > >> Chris > >> > >> _______________________________________________ > >> 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 > > > > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --e89a8f3ba17dd6d96404f11da310 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Jakob,

I thought we are mostly talking about initial time period after the session= is established and peer did not send EOR yet. So perhaps session reset wit= h right error is not that bad thing to do - if for nothing else then to sig= nal to the peer that his sequence is wrong ?

Or maybe we should do such things in = BGP Diagnostic Message ?

Best,
R.




=
On Wed, Jan 29, 2014 at 4:17 PM, Jakob Heitz <jakob.heitz@ericsson.com> wrote:
I don't think these minor errors are worth killing a session (and = all the other routes) for.
Get a BoRR, mark stale.
Get an EoRR or EoR, delete stale.
If you get two BoRR in a row, it just means the sender decided to abor= t a refresh and start a new one.
If in doubt, send another refresh request. You'll get another BoRR= in response, so don't overdo it.

--
Jakob Heitz.


On Jan 29, 2014, at 1:51 AM, "bruno.decraene@orange.com" <bruno.decraene@orange.co= m> wrote:

Hi all,

 

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Wednesday, January 29, 2014 10:15 AM
To: Dongjie (Jimmy)
Cc: Keyur Patel (keyupate); idr@ietf.org
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refre= sh

 

= Hi Jimmy and all,

=  

= I think Enke and Keyur's proposed text with help from Jakob makes the b= ehavior simplified and deterministic to hold on BoRR till first EoR is seen= .

=  

= IMHO it should be also spelled out what is the expected sequence error hand= ling here

 

[Bruno] +1= .  And taking into account possible interaction with draft-ietf-idr-bg= p-gr-notification

&nb= sp;

BTW:=

“Whe= n the BGP speaker detects an error while processing a ROUTE-REFRESH message= with a non-zero "Message Subtype" field, it MUST send a NOTIFICA= TION message with Error Code "ROUTE-REFRESH Message Error".”=

&nb= sp;

Seems a pr= iori not inline with the recommendation from draft-ietf-grow-ops-reqs-for-b= gp-error-handling (which is to limit the consequences of error handling). Are we sure that no error condition could be handled in a more = friendly way? (e.g. if BoRR is not sent following a “normal route ref= resh request” or if 2 BoRR are sent consecutively…)<= /u>

&nb= sp;

Thanks,=

Regards,

Bruno

&nb= sp;

&nb= sp;

... I think not following &= quot;MUST NOT" shall implicitly result in entire session drop and comp= lete restart ? Any error code ?

=  

= Best,
R.

=  

 <= /p>

On Wed, Jan 29, 2014 at 9:22 AM, Dongjie (Jimmy) <= ;jie.dong@huawei.c= om> wrote:

Hi Robert,

 

Agree that= in these cases the RRQ cannot be ignored, so postpone may be a better choi= ce.

 

While IMO = stop the initial update and start over may delay the initial convergence, and as you said  it also relates to update group processing. What do = you think about the new text provided by Keyur?

 

Best regards,

Jie

 

From: rraszuk@gmail.com [mailto:rraszuk@gm= ail.com] On Behalf Of Robert Raszuk
Sent: Sunday, January 26, 2014 11:03 PM
To: Dongjie (Jimmy)
Cc: Keyur Patel (keyupate); Jakob Heitz; idr@ietf.org


Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refre= sh

 

Hi Jie,

 

I think it actually very easy to say that initial update can= not ever guarantee that RRQ received during its sending may meet the peer's need.

 

Example 1:

 

SAFI 128 - During receiving initial update from RR to PE new= VRF got added with new RT import. Unfortunately those updates received within initial update were already dropped as not interesting by the PE. R= R must resend full table after completed initial update. (Of course this is= the case where there is no RTC and that's why RTC helps a lot here by = incremental nature). 

 

Example 2: 

 

SAFI 1 - Operator has modified inbound policy on EBGP peer d= uring processing of incoming updates and those originally were dropped. No soft reconfig in set. 

 

Conclusion:

 

RRQ can not ever be ignored. Sure they can be delayed or bat= ched (case of multiple peers within the same update/peer group) sending near RRQs (cluster of PEs got provisioned from central management = station). But as Keyur already mentioned those are rather standard local im= plementation optimizations. 

 

Question:

 

Does it maybe make sense to stop initial update when receivi= ng RRQ from a peer and start over ? Of course if peer is part of large update group it would have to be removed dynamically from it so othe= r members are not delayed. In any case I think this does not impact the spe= c but the implementation.

 

Cheers,
R.

 

 

 

On Sun, Jan 26, 2014 at 7:13 PM= , Dongjie (Jimmy) <jie.dong@huawei.com> wrote:

Hi Keyur, Jakob,

Agree that "postpone" may be better. The point is we could avoid = the complicated cases/considerations of performing route refresh during ini= tial update:)

For "ignore", I was thinking of scenarios in which the route refr= esh requirement may already be met by the initial update, while I'd adm= it it is hard to say...



Best regards,
Jie

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

From: Keyur Patel (keyupate) [m= ailto:keyupate@cisc= o.com]
Sent: Sunday, January 26, 2014 8:30 PM
To: Jakob Heitz; Dongjie (Jimmy)
Cc: idr@ietf.org
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Jie,

I agree with Jakob. You could make it *an implementation behavior* to postp= one the route refresh reply.


Regards,
Keyur

On 1/26/14 1:29 AM, "Jakob Heitz" <jakob.heitz@ericsson.com> wrote:<= br>
>You can definitely not ignore it, but you could postpone it.
>
>--
>Jakob Heitz.
>
>> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" <jie.dong@huawei.com>
>>wrote:
>>
>> After reading the analyses in this thread, my personal feeling is<= br> >>maybe we should avoid the interleaving between GR initial update an= d
>>route refresh/enhanced route refresh, since the initial update is j= ust
>>sending the whole Adj-RIB-Out, there is no obvious advantage to sta= rt
>>a route refresh/enhance route refresh during it. So a speaker shoul= d
>>ignore the RRQ received during the initial update. Thoughts?
>>
>> Best regards,
>> Jie
>>
>> -----Original Message-----
>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz
>> Sent: Saturday, January 25, 2014 10:48 PM
>> To: Chris Hall; = idr@ietf.org
>> Subject: Re: [Idr] WG LC for
>> draft-ietf-idr-bgp-enhanced-route-refresh
>>
>> RFCs are written for coders "practiced" in the art"= .
>> If anyone sends an EoRR before the adj-RIB-out is fully populated,=
>>then it's a BUG.
>> This does not need to be said.
>>
>> Personally, I believe a route refresh request should not be honore= d
>>until GR is complete.
>> Also, I don't believe a timer for the receipt of EoRR is neces= sary,
>>because the EoRR is guaranteed.
>> Guaranteed means "unless the session drops first".
>> --
>>
>> Jakob Heitz.
>>
>> ________________________________________
>> From: Chris Hall [chris.hall@highwayman.com]
>> Sent: Saturday, 25 January 2014 11:27 AM
>> To: idr@ietf.org=
>> Cc: Jakob Heitz
>> Subject: RE: [Idr] WG LC for
>> draft-ietf-idr-bgp-enhanced-route-refresh
>>
>> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37):
>> ...
>>> Silence means don't do it.
>>
>> Hmmm.... as a principle I'm more comfortable with "that w= hich isn't
>>prohibited is permitted"....
>>
>>> You would definitely NOT want BoRR to flush old stales.
>>
>> ....but, given the definite requirement, and given that the curren= t
>>precedent for "marking stale" does flush old stale, then = a few words
>>for the avoidance of doubt ?
>>
>>> Restarting the timer might be a good idea.
>>
>> I dunno... a route which remains stale for "a long time"= is, of
>>course, a candidate for being withdrawn: so having started a timer = the
>>first time things are set stale, I would avoid extending that -- at=
>>least for Graceful Restart, where the whole withdraw thing has been= "on-hold"
>>since the last session failed.  For route-refresh I guess ther= e's more
>>of a presumption that stale routes will be refreshed sooner or late= r,
>>and in the meantime they remain good.  So if the route-refresh= is
>>(repeatedly) restarted for some reason, perhaps it is more reasonab= le
>>to extend the flush deadline -- but avoid doing this indefinitely ?=
>>
>> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I ha= ve
>>built in Quagga prioritise route changes (pending changes and any t= hat
>>occur during the refresh) over refresh updates.  This makes it= more
>>likely that remaining stale routes are still good.  But the ot= her end
>>cannot know that.
>>
>> The paragraph in the draft discussing the "entire Adj-RIB-Out= "
>>defines that to be the entries present "at the start of the ro= ute
>>refresh operation", and observes that these comprise both reac= hable
>>and unreachable routes.  [An "of" after "compri= se" sets teeth on edge,
>>BTW.]  I'm really not sure what this paragraph is trying t= o tell me.
>> The reference to unreachable routes appears to suggest that pendin= g
>>withdraws should be sent as part of the refresh -- so not left to t= he
>>EoRR to implement at the end.  The point at which the EoRR is = sent is
>>defined such that it excludes any Adj-RIB-Out entries added after t= he
>>route-refresh started, but includes any which are changed during th= e
>>process.  It seems reasonable to delay any brand new reachable=
>>prefixes until after all previously announced ones have been refres= hed
>>and the EoRR sent -- if that's the intent here.  Changes w= hich occur
>>before the refresh gets to a given entry are pretty naturally swept= up
>>by the refresh.  Changes which occur after the refresh has gon= e past,
>>could/should be deferred to after the EoRR ?  Does it make a >>difference if the change is a withdraw ?  (Of course MRAI may = kick in here.  Ah.
>>MRAI and route-refresh, there's a topic !)
>>
>> I think the essence of the rule is that the EoRR should be sent on= ce
>>all prefixes previously advertised to the peer as reachable have be= en
>>refreshed, ie announced or withdrawn (at least) once.  Or, per= haps
>>more strictly, not *before* those prefixes have *all* been announce= d
>>once -- given that the EoRR will promptly bang un-advertised stuff = on the head.
>>Even more strictly perhaps: not send EoRR *before* any withdraws >>implied by it are required or desirable.
>>
>> Depending on the implementation, a given sender may or may not be<= br> >>able to determine the minimum set of updates required before sendin= g EoRR.
>>
>> If the refresh operation takes a long time, there may be good
>>routeing reasons to arrange for some route changes to be sent to th= e peer "early"
>>-- that is to send announcements which do not contribute to the
>>refresh, but which are important enough to warrant delaying the end= of
>>the refresh.  That could be a matter for recommendation(s) in = the standard.
>>
>> NB: given that the timing of the EoRR is tied to the state of the<= br> >>Adj-RIB-Out, I'm not sure about the Graceful Restart assumption= s.  At
>>the beginning of the initial update, the Restarting and Receiving >>speakers have:
>>
>>  Restarting:  Empty Adj-RIB-In   Empty Adj-RIB-Out<= br> >>
>>  Receiving:   Empty Adj-RIB-Out  Stale Adj-RIB-In >>
>> Now suppose (bonkers or otherwise) the receiving speaker sends an = RRQ
>>part way through the initial update.  The restarting speaker r= esponds
>>with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specifica= tion.
>> The receiving speaker sees the EoRR, and flushes stale.
>>Unfortunately, if the restarting speaker has not yet fully populate= d
>>its Adj-RIB-Out, then many further routes will be sent before the E= oR
>>falls due -- but the receiving speaker has already flushed their ti= ny
>>posteriors :-(
>>
>> I am coming to the view that route-refresh during a Graceful Resta= rt
>>initial update is a horse of a different colour altogether.
>>
>> [So the assumption that EoRR and EoR are triggered by the same thi= ng
>>was completely wrong, and I apologise for it.]
>>
>> Chris
>>
>> _______________________________________________
>> 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
htt= ps://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 message=
s electroniques etant susceptibles d'alteration,
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 authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

--e89a8f3ba17dd6d96404f11da310-- From jakob.heitz@ericsson.com Wed Jan 29 07:44:07 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 539B31A03FB for ; Wed, 29 Jan 2014 07:44:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XceXZi194hDM for ; Wed, 29 Jan 2014 07:44:03 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF9E1A03E0 for ; Wed, 29 Jan 2014 07:44:03 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-ed-52e921bc98a9 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 26.2E.12743.CB129E25; Wed, 29 Jan 2014 16:43:57 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0387.000; Wed, 29 Jan 2014 10:43:59 -0500 From: Jakob Heitz To: Robert Raszuk Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPF5KdKHMolEg8TF26AxOKep0T6JqRMOhAgAGfMAD//7gu+4AAX1gA//+1BTCAAHhgAP//sQGgAA5+ToAABygAoAAmsOcAAAoIr7AAJlf4AP//r6/0gAEnPAD//8BcWoAA2iqAgAAMEwCAAB6LgIAD81WAgAAOsoCAAAoOAIAAB0uLgABX8ID//6+RJg== Date: Wed, 29 Jan 2014 15:43:57 +0000 Message-ID: References: <00AB3F7F-5E33-4533-96C7-E7F75A3E76CB@ericsson.com> <76CD132C3ADEF848BD84D028D243C927335C435C@nkgeml512-mbx.china.huawei.com> <76CD132C3ADEF848BD84D028D243C927335C6B18@nkgeml512-mbx.china.huawei.com> <6650_1390989061_52E8CF05_6650_399_1_53C29892C857584299CBF5D05346208A070DFED8@PEXCVZYM11.corporate.adroot.infra.ftgroup> <0C0CE57B-CA57-471D-BE3C-8B5F380BE087@ericsson.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_FE2C430F4AAE4DB08AEACF16CD6136F5ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyuXRPoO5exZdBBnemslv82DGH2eLV7WdM Fo1bz7NZNC1sYnZg8ZjyeyOrx5IlP5k8Wp6dZPPYvXEBUwBLFJdNSmpOZllqkb5dAldGd/cG loLTd5kqvq58ytrAeGkNUxcjJ4eEgInErh0PWCFsMYkL99azdTFycQgJHGGU+HPlKCOEs5xR 4sPpL8wgVWwCOhLfrneB2SICqhKdJx4xgxQxC3QzSpxd0cgGkhAWcJN4NWk5O0SRu0TLj0lQ DecYJd6+CQexWYCaf67dDlbDK2AvMW/aHVaIbY2sEk0/poM1cAoESkycPgXMZgS67/spiLuZ BcQlbj2ZD/WDgMSSPeeZIWxRiZeP/7FC1CRLfD//hg1igaDEyZlPWCYwisxC0j4LSdksJGUQ cQOJ9+fmM0PY2hLLFr6GsvUlNn45y4gsvoCRfRUjR2lxalluupHBJkZgvB2TYNPdwbjnpeUh RmkOFiVx3i9vnYOEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MGZcq9Sb/NVO0GVm0JW1VWeT 3/1IMHgXuCQnWkHE1jxGwnLH15O6NiHr8yNqfX7dKp6u4cg0IX3y2WzT1q0ntWW1th00STu7 MOyz8bzTylUv311cEn1J5pP40hPczjny82dmP7didX/hdiVif/uE4EPMW66Lid+OeKv3ITMk u23ZdGF9D5F8byWW4oxEQy3mouJEAOZD/UCFAgAA Cc: "Keyur Patel \(keyupate\)" , "bruno.decraene@orange.com" , "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 15:44:07 -0000 --_000_FE2C430F4AAE4DB08AEACF16CD6136F5ericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable If you kill a session doing GR, it kills all the stale routes. It's a bad t= hing. -- Jakob Heitz. On Jan 29, 2014, at 7:31 AM, "Robert Raszuk" > wrote: Hi Jakob, I thought we are mostly talking about initial time period after the session= is established and peer did not send EOR yet. So perhaps session reset wit= h right error is not that bad thing to do - if for nothing else then to sig= nal to the peer that his sequence is wrong ? Or maybe we should do such things in BGP Diagnostic Message ? Best, R. On Wed, Jan 29, 2014 at 4:17 PM, Jakob Heitz > wrote: I don't think these minor errors are worth killing a session (and all the o= ther routes) for. Get a BoRR, mark stale. Get an EoRR or EoR, delete stale. If you get two BoRR in a row, it just means the sender decided to abort a r= efresh and start a new one. If in doubt, send another refresh request. You'll get another BoRR in respo= nse, so don't overdo it. -- Jakob Heitz. On Jan 29, 2014, at 1:51 AM, "bruno.decraene@orange.com" > wrote: Hi all, From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: Wednesday, January 29, 2014 10:15 AM To: Dongjie (Jimmy) Cc: Keyur Patel (keyupate); idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Jimmy and all, I think Enke and Keyur's proposed text with help from Jakob makes the behav= ior simplified and deterministic to hold on BoRR till first EoR is seen. IMHO it should be also spelled out what is the expected sequence error hand= ling here [Bruno] +1. And taking into account possible interaction with draft-ietf-i= dr-bgp-gr-notification BTW: =93When the BGP speaker detects an error while processing a ROUTE-REFRESH m= essage with a non-zero "Message Subtype" field, it MUST send a NOTIFICATION= message with Error Code "ROUTE-REFRESH Message Error".=94 Seems a priori not inline with the recommendation from draft-ietf-grow-ops-= reqs-for-bgp-error-handling (which is to limit the consequences of error ha= ndling). Are we sure that no error condition could be handled in a more fri= endly way? (e.g. if BoRR is not sent following a =93normal route refresh re= quest=94 or if 2 BoRR are sent consecutively=85) Thanks, Regards, Bruno ... I think not following "MUST NOT" shall implicitly result in entire sess= ion drop and complete restart ? Any error code ? Best, R. On Wed, Jan 29, 2014 at 9:22 AM, Dongjie (Jimmy) > wrote: Hi Robert, Agree that in these cases the RRQ cannot be ignored, so postpone may be a b= etter choice. While IMO stop the initial update and start over may delay the initial conv= ergence, and as you said it also relates to update group processing. What = do you think about the new text provided by Keyur? Best regards, Jie From: rraszuk@gmail.com [mailto:rraszuk@gmail.com= ] On Behalf Of Robert Raszuk Sent: Sunday, January 26, 2014 11:03 PM To: Dongjie (Jimmy) Cc: Keyur Patel (keyupate); Jakob Heitz; idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Jie, I think it actually very easy to say that initial update can not ever guara= ntee that RRQ received during its sending may meet the peer's need. Example 1: SAFI 128 - During receiving initial update from RR to PE new VRF got added = with new RT import. Unfortunately those updates received within initial upd= ate were already dropped as not interesting by the PE. RR must resend full = table after completed initial update. (Of course this is the case where the= re is no RTC and that's why RTC helps a lot here by incremental nature). Example 2: SAFI 1 - Operator has modified inbound policy on EBGP peer during processin= g of incoming updates and those originally were dropped. No soft reconfig i= n set. Conclusion: RRQ can not ever be ignored. Sure they can be delayed or batched (case of m= ultiple peers within the same update/peer group) sending near RRQs (cluster= of PEs got provisioned from central management station). But as Keyur alre= ady mentioned those are rather standard local implementation optimizations. Question: Does it maybe make sense to stop initial update when receiving RRQ from a p= eer and start over ? Of course if peer is part of large update group it wou= ld have to be removed dynamically from it so other members are not delayed.= In any case I think this does not impact the spec but the implementation. Cheers, R. On Sun, Jan 26, 2014 at 7:13 PM, Dongjie (Jimmy) > wrote: Hi Keyur, Jakob, Agree that "postpone" may be better. The point is we could avoid the compli= cated cases/considerations of performing route refresh during initial updat= e:) For "ignore", I was thinking of scenarios in which the route refresh requir= ement may already be met by the initial update, while I'd admit it is hard = to say... Best regards, Jie -----Original Message----- From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] Sent: Sunday, January 26, 2014 8:30 PM To: Jakob Heitz; Dongjie (Jimmy) Cc: idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Jie, I agree with Jakob. You could make it *an implementation behavior* to postp= one the route refresh reply. Regards, Keyur On 1/26/14 1:29 AM, "Jakob Heitz" > wrote: >You can definitely not ignore it, but you could postpone it. > >-- >Jakob Heitz. > >> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" > >>wrote: >> >> After reading the analyses in this thread, my personal feeling is >>maybe we should avoid the interleaving between GR initial update and >>route refresh/enhanced route refresh, since the initial update is just >>sending the whole Adj-RIB-Out, there is no obvious advantage to start >>a route refresh/enhance route refresh during it. So a speaker should >>ignore the RRQ received during the initial update. Thoughts? >> >> Best regards, >> Jie >> >> -----Original Message----- >> From: Idr [mailto:idr-bounces@ietf.org] On = Behalf Of Jakob Heitz >> Sent: Saturday, January 25, 2014 10:48 PM >> To: Chris Hall; idr@ietf.org >> Subject: Re: [Idr] WG LC for >> draft-ietf-idr-bgp-enhanced-route-refresh >> >> RFCs are written for coders "practiced" in the art". >> If anyone sends an EoRR before the adj-RIB-out is fully populated, >>then it's a BUG. >> This does not need to be said. >> >> Personally, I believe a route refresh request should not be honored >>until GR is complete. >> Also, I don't believe a timer for the receipt of EoRR is necessary, >>because the EoRR is guaranteed. >> Guaranteed means "unless the session drops first". >> -- >> >> Jakob Heitz. >> >> ________________________________________ >> From: Chris Hall [chris.hall@highwayman.com] >> Sent: Saturday, 25 January 2014 11:27 AM >> To: idr@ietf.org >> Cc: Jakob Heitz >> Subject: RE: [Idr] WG LC for >> draft-ietf-idr-bgp-enhanced-route-refresh >> >> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): >> ... >>> Silence means don't do it. >> >> Hmmm.... as a principle I'm more comfortable with "that which isn't >>prohibited is permitted".... >> >>> You would definitely NOT want BoRR to flush old stales. >> >> ....but, given the definite requirement, and given that the current >>precedent for "marking stale" does flush old stale, then a few words >>for the avoidance of doubt ? >> >>> Restarting the timer might be a good idea. >> >> I dunno... a route which remains stale for "a long time" is, of >>course, a candidate for being withdrawn: so having started a timer the >>first time things are set stale, I would avoid extending that -- at >>least for Graceful Restart, where the whole withdraw thing has been "on-h= old" >>since the last session failed. For route-refresh I guess there's more >>of a presumption that stale routes will be refreshed sooner or later, >>and in the meantime they remain good. So if the route-refresh is >>(repeatedly) restarted for some reason, perhaps it is more reasonable >>to extend the flush deadline -- but avoid doing this indefinitely ? >> >> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I have >>built in Quagga prioritise route changes (pending changes and any that >>occur during the refresh) over refresh updates. This makes it more >>likely that remaining stale routes are still good. But the other end >>cannot know that. >> >> The paragraph in the draft discussing the "entire Adj-RIB-Out" >>defines that to be the entries present "at the start of the route >>refresh operation", and observes that these comprise both reachable >>and unreachable routes. [An "of" after "comprise" sets teeth on edge, >>BTW.] I'm really not sure what this paragraph is trying to tell me. >> The reference to unreachable routes appears to suggest that pending >>withdraws should be sent as part of the refresh -- so not left to the >>EoRR to implement at the end. The point at which the EoRR is sent is >>defined such that it excludes any Adj-RIB-Out entries added after the >>route-refresh started, but includes any which are changed during the >>process. It seems reasonable to delay any brand new reachable >>prefixes until after all previously announced ones have been refreshed >>and the EoRR sent -- if that's the intent here. Changes which occur >>before the refresh gets to a given entry are pretty naturally swept up >>by the refresh. Changes which occur after the refresh has gone past, >>could/should be deferred to after the EoRR ? Does it make a >>difference if the change is a withdraw ? (Of course MRAI may kick in her= e. Ah. >>MRAI and route-refresh, there's a topic !) >> >> I think the essence of the rule is that the EoRR should be sent once >>all prefixes previously advertised to the peer as reachable have been >>refreshed, ie announced or withdrawn (at least) once. Or, perhaps >>more strictly, not *before* those prefixes have *all* been announced >>once -- given that the EoRR will promptly bang un-advertised stuff on the= head. >>Even more strictly perhaps: not send EoRR *before* any withdraws >>implied by it are required or desirable. >> >> Depending on the implementation, a given sender may or may not be >>able to determine the minimum set of updates required before sending EoRR= . >> >> If the refresh operation takes a long time, there may be good >>routeing reasons to arrange for some route changes to be sent to the peer= "early" >>-- that is to send announcements which do not contribute to the >>refresh, but which are important enough to warrant delaying the end of >>the refresh. That could be a matter for recommendation(s) in the standar= d. >> >> NB: given that the timing of the EoRR is tied to the state of the >>Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. At >>the beginning of the initial update, the Restarting and Receiving >>speakers have: >> >> Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out >> >> Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In >> >> Now suppose (bonkers or otherwise) the receiving speaker sends an RRQ >>part way through the initial update. The restarting speaker responds >>with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specification. >> The receiving speaker sees the EoRR, and flushes stale. >>Unfortunately, if the restarting speaker has not yet fully populated >>its Adj-RIB-Out, then many further routes will be sent before the EoR >>falls due -- but the receiving speaker has already flushed their tiny >>posteriors :-( >> >> I am coming to the view that route-refresh during a Graceful Restart >>initial update is a horse of a different colour altogether. >> >> [So the assumption that EoRR and EoR are triggered by the same thing >>was completely wrong, and I apologise for it.] >> >> Chris >> >> _______________________________________________ >> 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 ___________________________________________________________________________= ______________________________________________ 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, 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 authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_FE2C430F4AAE4DB08AEACF16CD6136F5ericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
If you kill a session doing GR, it kills all the stale routes. It's a = bad thing.

--
Jakob Heitz.


On Jan 29, 2014, at 7:31 AM, "Robert Raszuk" <robert@raszuk.net> wrote:

Hi Jakob,

I thought we are mostly talking about initial time period after the session= is established and peer did not send EOR yet. So perhaps session reset wit= h right error is not that bad thing to do - if for nothing else then to sig= nal to the peer that his sequence is wrong ?

Or maybe we should do such things in BGP Diagnostic Message ?

Best,
R.




On Wed, Jan 29, 2014 at 4:17 PM, Jakob Heitz <jakob.hei= tz@ericsson.com> wrote:
I don't think these minor errors are worth killing a session (and all = the other routes) for.
Get a BoRR, mark stale.
Get an EoRR or EoR, delete stale.
If you get two BoRR in a row, it just means the sender decided to abor= t a refresh and start a new one.
If in doubt, send another refresh request. You'll get another BoRR in = response, so don't overdo it.

--
Jakob Heitz.


On Jan 29, 2014, at 1:51 AM, "bruno.decraene@orange.com" <bruno.decraene@orange.co= m> wrote:

Hi all,

 

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Wednesday, January 29, 2014 10:15 AM
To: Dongjie (Jimmy)
Cc: Keyur Patel (keyupate); idr@ietf.org
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refre= sh

 

= Hi Jimmy and all,

=  

= I think Enke and Keyur's proposed text with help from Jakob makes the behav= ior simplified and deterministic to hold on BoRR till first EoR is seen.=

=  

= IMHO it should be also spelled out what is the expected sequence error hand= ling here

 

[Bruno] &#= 43;1.  And taking into account possible interaction with draft-ietf-id= r-bgp-gr-notification

&nb= sp;

BTW:=

=93When th= e BGP speaker detects an error while processing a ROUTE-REFRESH message wit= h a non-zero "Message Subtype" field, it MUST send a NOTIFICATION message with Error Code "ROUTE-REFRESH Message Error".=94=

&nb= sp;

Seems a pr= iori not inline with the recommendation from draft-ietf-grow-ops-reqs-for-b= gp-error-handling (which is to limit the consequences of error handling). Are we sure that no error condition could be handled in a more = friendly way? (e.g. if BoRR is not sent following a =93normal route refresh= request=94 or if 2 BoRR are sent consecutively=85)

&nb= sp;

Thanks,=

Regards,

Bruno

&nb= sp;

&nb= sp;

... I think not following &= quot;MUST NOT" shall implicitly result in entire session drop and comp= lete restart ? Any error code ?

=  

= Best,
R.

=  

 <= /p>

On Wed, Jan 29, 2014 at 9:22 AM, Dongjie (Jimmy) <= ;jie.dong@huawei.c= om> wrote:

Hi Robert,

 

Agree that= in these cases the RRQ cannot be ignored, so postpone may be a better choi= ce.

 

While IMO = stop the initial update and start over may delay the initial convergence, a= nd as you said  it also relates to update group processing. What do you think about the new text provided by Keyur? <= /u>

 

Best regards,

Jie

 

From: rraszuk@gmail.com [mailto:rraszuk@gm= ail.com] On Behalf Of Robert Raszuk
Sent: Sunday, January 26, 2014 11:03 PM
To: Dongjie (Jimmy)
Cc: Keyur Patel (keyupate); Jakob Heitz; idr@ietf.org


Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refre= sh

 

Hi Jie,

 

I think it actually very easy to say that initial update can= not ever guarantee that RRQ received during its sending may meet the peer'= s need.

 

Example 1:

 

SAFI 128 - During receiving initial update from RR to PE new= VRF got added with new RT import. Unfortunately those updates received wit= hin initial update were already dropped as not interesting by the PE. RR must resend full table after completed initial update. (Of c= ourse this is the case where there is no RTC and that's why RTC helps a lot= here by incremental nature). 

 

Example 2: 

 

SAFI 1 - Operator has modified inbound policy on EBGP peer d= uring processing of incoming updates and those originally were dropped. No = soft reconfig in set. 

 

Conclusion:

 

RRQ can not ever be ignored. Sure they can be delayed or bat= ched (case of multiple peers within the same update/peer group) sending nea= r RRQs (cluster of PEs got provisioned from central management station). But as Keyur already mentioned those are rather stand= ard local implementation optimizations. 

 

Question:

 

Does it maybe make sense to stop initial update when receivi= ng RRQ from a peer and start over ? Of course if peer is part of large upda= te group it would have to be removed dynamically from it so other members are not delayed. In any case I think this does no= t impact the spec but the implementation.

 

Cheers,
R.

 

 

 

On Sun, Jan 26, 2014 at 7:13 PM= , Dongjie (Jimmy) <jie.dong@huawei.com> wrote:

Hi Keyur, Jakob,

Agree that "postpone" may be better. The point is we could avoid = the complicated cases/considerations of performing route refresh during ini= tial update:)

For "ignore", I was thinking of scenarios in which the route refr= esh requirement may already be met by the initial update, while I'd admit i= t is hard to say...



Best regards,
Jie

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

From: Keyur Patel (keyupate) [m= ailto:keyupate@cisc= o.com]
Sent: Sunday, January 26, 2014 8:30 PM
To: Jakob Heitz; Dongjie (Jimmy)
Cc: idr@ietf.org
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Jie,

I agree with Jakob. You could make it *an implementation behavior* to postp= one the route refresh reply.


Regards,
Keyur

On 1/26/14 1:29 AM, "Jakob Heitz" <jakob.heitz@ericsson.com> wrote:<= br>
>You can definitely not ignore it, but you could postpone it.
>
>--
>Jakob Heitz.
>
>> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" <jie.dong@huawei.com>
>>wrote:
>>
>> After reading the analyses in this thread, my personal feeling is<= br> >>maybe we should avoid the interleaving between GR initial update an= d
>>route refresh/enhanced route refresh, since the initial update is j= ust
>>sending the whole Adj-RIB-Out, there is no obvious advantage to sta= rt
>>a route refresh/enhance route refresh during it. So a speaker shoul= d
>>ignore the RRQ received during the initial update. Thoughts?
>>
>> Best regards,
>> Jie
>>
>> -----Original Message-----
>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz
>> Sent: Saturday, January 25, 2014 10:48 PM
>> To: Chris Hall; = idr@ietf.org
>> Subject: Re: [Idr] WG LC for
>> draft-ietf-idr-bgp-enhanced-route-refresh
>>
>> RFCs are written for coders "practiced" in the art"= .
>> If anyone sends an EoRR before the adj-RIB-out is fully populated,=
>>then it's a BUG.
>> This does not need to be said.
>>
>> Personally, I believe a route refresh request should not be honore= d
>>until GR is complete.
>> Also, I don't believe a timer for the receipt of EoRR is necessary= ,
>>because the EoRR is guaranteed.
>> Guaranteed means "unless the session drops first".
>> --
>>
>> Jakob Heitz.
>>
>> ________________________________________
>> From: Chris Hall [chris.hall@highwayman.com]
>> Sent: Saturday, 25 January 2014 11:27 AM
>> To: idr@ietf.org=
>> Cc: Jakob Heitz
>> Subject: RE: [Idr] WG LC for
>> draft-ietf-idr-bgp-enhanced-route-refresh
>>
>> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37):
>> ...
>>> Silence means don't do it.
>>
>> Hmmm.... as a principle I'm more comfortable with "that which= isn't
>>prohibited is permitted"....
>>
>>> You would definitely NOT want BoRR to flush old stales.
>>
>> ....but, given the definite requirement, and given that the curren= t
>>precedent for "marking stale" does flush old stale, then = a few words
>>for the avoidance of doubt ?
>>
>>> Restarting the timer might be a good idea.
>>
>> I dunno... a route which remains stale for "a long time"= is, of
>>course, a candidate for being withdrawn: so having started a timer = the
>>first time things are set stale, I would avoid extending that -- at=
>>least for Graceful Restart, where the whole withdraw thing has been= "on-hold"
>>since the last session failed.  For route-refresh I guess ther= e's more
>>of a presumption that stale routes will be refreshed sooner or late= r,
>>and in the meantime they remain good.  So if the route-refresh= is
>>(repeatedly) restarted for some reason, perhaps it is more reasonab= le
>>to extend the flush deadline -- but avoid doing this indefinitely ?=
>>
>> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I ha= ve
>>built in Quagga prioritise route changes (pending changes and any t= hat
>>occur during the refresh) over refresh updates.  This makes it= more
>>likely that remaining stale routes are still good.  But the ot= her end
>>cannot know that.
>>
>> The paragraph in the draft discussing the "entire Adj-RIB-Out= "
>>defines that to be the entries present "at the start of the ro= ute
>>refresh operation", and observes that these comprise both reac= hable
>>and unreachable routes.  [An "of" after "compri= se" sets teeth on edge,
>>BTW.]  I'm really not sure what this paragraph is trying to te= ll me.
>> The reference to unreachable routes appears to suggest that pendin= g
>>withdraws should be sent as part of the refresh -- so not left to t= he
>>EoRR to implement at the end.  The point at which the EoRR is = sent is
>>defined such that it excludes any Adj-RIB-Out entries added after t= he
>>route-refresh started, but includes any which are changed during th= e
>>process.  It seems reasonable to delay any brand new reachable=
>>prefixes until after all previously announced ones have been refres= hed
>>and the EoRR sent -- if that's the intent here.  Changes which= occur
>>before the refresh gets to a given entry are pretty naturally swept= up
>>by the refresh.  Changes which occur after the refresh has gon= e past,
>>could/should be deferred to after the EoRR ?  Does it make a >>difference if the change is a withdraw ?  (Of course MRAI may = kick in here.  Ah.
>>MRAI and route-refresh, there's a topic !)
>>
>> I think the essence of the rule is that the EoRR should be sent on= ce
>>all prefixes previously advertised to the peer as reachable have be= en
>>refreshed, ie announced or withdrawn (at least) once.  Or, per= haps
>>more strictly, not *before* those prefixes have *all* been announce= d
>>once -- given that the EoRR will promptly bang un-advertised stuff = on the head.
>>Even more strictly perhaps: not send EoRR *before* any withdraws >>implied by it are required or desirable.
>>
>> Depending on the implementation, a given sender may or may not be<= br> >>able to determine the minimum set of updates required before sendin= g EoRR.
>>
>> If the refresh operation takes a long time, there may be good
>>routeing reasons to arrange for some route changes to be sent to th= e peer "early"
>>-- that is to send announcements which do not contribute to the
>>refresh, but which are important enough to warrant delaying the end= of
>>the refresh.  That could be a matter for recommendation(s) in = the standard.
>>
>> NB: given that the timing of the EoRR is tied to the state of the<= br> >>Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. &= nbsp;At
>>the beginning of the initial update, the Restarting and Receiving >>speakers have:
>>
>>  Restarting:  Empty Adj-RIB-In   Empty Adj-RIB-Out<= br> >>
>>  Receiving:   Empty Adj-RIB-Out  Stale Adj-RIB-In >>
>> Now suppose (bonkers or otherwise) the receiving speaker sends an = RRQ
>>part way through the initial update.  The restarting speaker r= esponds
>>with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specifica= tion.
>> The receiving speaker sees the EoRR, and flushes stale.
>>Unfortunately, if the restarting speaker has not yet fully populate= d
>>its Adj-RIB-Out, then many further routes will be sent before the E= oR
>>falls due -- but the receiving speaker has already flushed their ti= ny
>>posteriors :-(
>>
>> I am coming to the view that route-refresh during a Graceful Resta= rt
>>initial update is a horse of a different colour altogether.
>>
>> [So the assumption that EoRR and EoR are triggered by the same thi= ng
>>was completely wrong, and I apologise for it.]
>>
>> Chris
>>
>> _______________________________________________
>> 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
htt= ps://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,
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 authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

--_000_FE2C430F4AAE4DB08AEACF16CD6136F5ericssoncom_-- From rraszuk@gmail.com Wed Jan 29 07:47:27 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21EAA1A0218 for ; Wed, 29 Jan 2014 07:47:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9ACL0BQYIg6 for ; Wed, 29 Jan 2014 07:47:22 -0800 (PST) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 5078C1A008E for ; Wed, 29 Jan 2014 07:47:22 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id to1so2228096ieb.0 for ; Wed, 29 Jan 2014 07:47:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=SXipWTMGX3d/EDFgvSJrFIMpWIF805JkYILBCHU2Kew=; b=PzbhHbxDX5BpiyQZioNg+c7Jhw01zwpJjJIEx6VdqeEs+NGnifGqL5yClHEfg42EBe dgT6EAIUh5XNUAyGsgMK20LR7ounk146Nfgvt8ts9cU/kTYvP6TFYtEgpUrEchxWUtV4 NuHLz6dtsu4HjPaGcUZtTP3AlsZhEAPigo+HXc3cTyQqnKBkwB/4sEkuz4YABn/Rp//q mnAIlJ4j6ChS1+0LusXz4pMLBBhjUI0Hn1fq1uygJSz1q6RYHHP3fE5NVq5kRSkrX18r 73CTG+YNXANOhHjobLmuSNRNm2ZXkzyDbT3eVCe3uGVsilp8Gx9DIC7DZAPxTzH+qrnT vTJA== MIME-Version: 1.0 X-Received: by 10.42.33.65 with SMTP id h1mr1338223icd.72.1391010439213; Wed, 29 Jan 2014 07:47:19 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.212.8 with HTTP; Wed, 29 Jan 2014 07:47:19 -0800 (PST) In-Reply-To: References: <00AB3F7F-5E33-4533-96C7-E7F75A3E76CB@ericsson.com> <76CD132C3ADEF848BD84D028D243C927335C435C@nkgeml512-mbx.china.huawei.com> <76CD132C3ADEF848BD84D028D243C927335C6B18@nkgeml512-mbx.china.huawei.com> <6650_1390989061_52E8CF05_6650_399_1_53C29892C857584299CBF5D05346208A070DFED8@PEXCVZYM11.corporate.adroot.infra.ftgroup> <0C0CE57B-CA57-471D-BE3C-8B5F380BE087@ericsson.com> Date: Wed, 29 Jan 2014 16:47:19 +0100 X-Google-Sender-Auth: zICDWaxbcyJUBVPCAksBxPqcJWM Message-ID: From: Robert Raszuk To: Jakob Heitz Content-Type: multipart/alternative; boundary=bcaec51827b81bb97c04f11ddb23 Cc: "Keyur Patel \(keyupate\)" , "bruno.decraene@orange.com" , "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 15:47:27 -0000 --bcaec51827b81bb97c04f11ddb23 Content-Type: text/plain; charset=ISO-8859-1 When the session comes up after let's say peer up there is no stale routes .. are there ? So the whole point of GR is not to kill the routes before timeout and lack of new complete table from a peer followed by EOR. Perhaps we have different cases in mind .... r. On Wed, Jan 29, 2014 at 4:43 PM, Jakob Heitz wrote: > If you kill a session doing GR, it kills all the stale routes. It's a > bad thing. > > -- > Jakob Heitz. > > > On Jan 29, 2014, at 7:31 AM, "Robert Raszuk" wrote: > > Hi Jakob, > > I thought we are mostly talking about initial time period after the > session is established and peer did not send EOR yet. So perhaps session > reset with right error is not that bad thing to do - if for nothing else > then to signal to the peer that his sequence is wrong ? > > Or maybe we should do such things in BGP Diagnostic Message ? > > Best, > R. > > > > > On Wed, Jan 29, 2014 at 4:17 PM, Jakob Heitz wrote: > >> I don't think these minor errors are worth killing a session (and all >> the other routes) for. >> Get a BoRR, mark stale. >> Get an EoRR or EoR, delete stale. >> If you get two BoRR in a row, it just means the sender decided to abort a >> refresh and start a new one. >> If in doubt, send another refresh request. You'll get another BoRR in >> response, so don't overdo it. >> >> -- >> Jakob Heitz. >> >> >> On Jan 29, 2014, at 1:51 AM, "bruno.decraene@orange.com" < >> bruno.decraene@orange.com> wrote: >> >> Hi all, >> >> >> >> >> >> *From:* Idr [mailto:idr-bounces@ietf.org ] *On >> Behalf Of *Robert Raszuk >> *Sent:* Wednesday, January 29, 2014 10:15 AM >> *To:* Dongjie (Jimmy) >> *Cc:* Keyur Patel (keyupate); idr@ietf.org >> *Subject:* Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh >> >> >> >> Hi Jimmy and all, >> >> >> >> I think Enke and Keyur's proposed text with help from Jakob makes the >> behavior simplified and deterministic to hold on BoRR till first EoR is >> seen. >> >> >> >> IMHO it should be also spelled out what is the expected sequence error >> handling here >> >> >> >> [Bruno] +1. And taking into account possible interaction with >> draft-ietf-idr-bgp-gr-notification >> >> >> >> BTW: >> >> "When the BGP speaker detects an error while processing a ROUTE-REFRESH >> message with a non-zero "Message Subtype" field, it MUST send a >> NOTIFICATION message with Error Code "ROUTE-REFRESH Message Error"." >> >> >> >> Seems a priori not inline with the recommendation from >> draft-ietf-grow-ops-reqs-for-bgp-error-handling (which is to limit the >> consequences of error handling). Are we sure that no error condition could >> be handled in a more friendly way? (e.g. if BoRR is not sent following a >> "normal route refresh request" or if 2 BoRR are sent consecutively...) >> >> >> >> Thanks, >> >> Regards, >> >> Bruno >> >> >> >> >> >> ... I think not following "MUST NOT" shall implicitly result in entire >> session drop and complete restart ? Any error code ? >> >> >> >> Best, >> R. >> >> >> >> >> >> On Wed, Jan 29, 2014 at 9:22 AM, Dongjie (Jimmy) >> wrote: >> >> Hi Robert, >> >> >> >> Agree that in these cases the RRQ cannot be ignored, so postpone may be a >> better choice. >> >> >> >> While IMO stop the initial update and start over may delay the initial >> convergence, and as you said it also relates to update group processing. >> What do you think about the new text provided by Keyur? >> >> >> >> Best regards, >> >> Jie >> >> >> >> *From:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Robert >> Raszuk >> *Sent:* Sunday, January 26, 2014 11:03 PM >> *To:* Dongjie (Jimmy) >> *Cc:* Keyur Patel (keyupate); Jakob Heitz; idr@ietf.org >> >> >> *Subject:* Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh >> >> >> >> Hi Jie, >> >> >> >> I think it actually very easy to say that initial update can not ever >> guarantee that RRQ received during its sending may meet the peer's need. >> >> >> >> Example 1: >> >> >> >> SAFI 128 - During receiving initial update from RR to PE new VRF got >> added with new RT import. Unfortunately those updates received within >> initial update were already dropped as not interesting by the PE. RR must >> resend full table after completed initial update. (Of course this is the >> case where there is no RTC and that's why RTC helps a lot here by >> incremental nature). >> >> >> >> Example 2: >> >> >> >> SAFI 1 - Operator has modified inbound policy on EBGP peer during >> processing of incoming updates and those originally were dropped. No soft >> reconfig in set. >> >> >> >> Conclusion: >> >> >> >> RRQ can not ever be ignored. Sure they can be delayed or batched (case of >> multiple peers within the same update/peer group) sending near RRQs >> (cluster of PEs got provisioned from central management station). But as >> Keyur already mentioned those are rather standard local implementation >> optimizations. >> >> >> >> Question: >> >> >> >> Does it maybe make sense to stop initial update when receiving RRQ from a >> peer and start over ? Of course if peer is part of large update group it >> would have to be removed dynamically from it so other members are not >> delayed. In any case I think this does not impact the spec but the >> implementation. >> >> >> >> Cheers, >> R. >> >> >> >> >> >> >> >> On Sun, Jan 26, 2014 at 7:13 PM, Dongjie (Jimmy) >> wrote: >> >> Hi Keyur, Jakob, >> >> Agree that "postpone" may be better. The point is we could avoid the >> complicated cases/considerations of performing route refresh during initial >> update:) >> >> For "ignore", I was thinking of scenarios in which the route refresh >> requirement may already be met by the initial update, while I'd admit it is >> hard to say... >> >> >> >> Best regards, >> Jie >> >> -----Original Message----- >> >> From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] >> Sent: Sunday, January 26, 2014 8:30 PM >> To: Jakob Heitz; Dongjie (Jimmy) >> Cc: idr@ietf.org >> Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh >> >> Jie, >> >> I agree with Jakob. You could make it *an implementation behavior* to >> postpone the route refresh reply. >> >> >> Regards, >> Keyur >> >> On 1/26/14 1:29 AM, "Jakob Heitz" wrote: >> >> >You can definitely not ignore it, but you could postpone it. >> > >> >-- >> >Jakob Heitz. >> > >> >> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" >> >>wrote: >> >> >> >> After reading the analyses in this thread, my personal feeling is >> >>maybe we should avoid the interleaving between GR initial update and >> >>route refresh/enhanced route refresh, since the initial update is just >> >>sending the whole Adj-RIB-Out, there is no obvious advantage to start >> >>a route refresh/enhance route refresh during it. So a speaker should >> >>ignore the RRQ received during the initial update. Thoughts? >> >> >> >> Best regards, >> >> Jie >> >> >> >> -----Original Message----- >> >> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz >> >> Sent: Saturday, January 25, 2014 10:48 PM >> >> To: Chris Hall; idr@ietf.org >> >> Subject: Re: [Idr] WG LC for >> >> draft-ietf-idr-bgp-enhanced-route-refresh >> >> >> >> RFCs are written for coders "practiced" in the art". >> >> If anyone sends an EoRR before the adj-RIB-out is fully populated, >> >>then it's a BUG. >> >> This does not need to be said. >> >> >> >> Personally, I believe a route refresh request should not be honored >> >>until GR is complete. >> >> Also, I don't believe a timer for the receipt of EoRR is necessary, >> >>because the EoRR is guaranteed. >> >> Guaranteed means "unless the session drops first". >> >> -- >> >> >> >> Jakob Heitz. >> >> >> >> ________________________________________ >> >> From: Chris Hall [chris.hall@highwayman.com] >> >> Sent: Saturday, 25 January 2014 11:27 AM >> >> To: idr@ietf.org >> >> Cc: Jakob Heitz >> >> Subject: RE: [Idr] WG LC for >> >> draft-ietf-idr-bgp-enhanced-route-refresh >> >> >> >> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): >> >> ... >> >>> Silence means don't do it. >> >> >> >> Hmmm.... as a principle I'm more comfortable with "that which isn't >> >>prohibited is permitted".... >> >> >> >>> You would definitely NOT want BoRR to flush old stales. >> >> >> >> ....but, given the definite requirement, and given that the current >> >>precedent for "marking stale" does flush old stale, then a few words >> >>for the avoidance of doubt ? >> >> >> >>> Restarting the timer might be a good idea. >> >> >> >> I dunno... a route which remains stale for "a long time" is, of >> >>course, a candidate for being withdrawn: so having started a timer the >> >>first time things are set stale, I would avoid extending that -- at >> >>least for Graceful Restart, where the whole withdraw thing has been >> "on-hold" >> >>since the last session failed. For route-refresh I guess there's more >> >>of a presumption that stale routes will be refreshed sooner or later, >> >>and in the meantime they remain good. So if the route-refresh is >> >>(repeatedly) restarted for some reason, perhaps it is more reasonable >> >>to extend the flush deadline -- but avoid doing this indefinitely ? >> >> >> >> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I have >> >>built in Quagga prioritise route changes (pending changes and any that >> >>occur during the refresh) over refresh updates. This makes it more >> >>likely that remaining stale routes are still good. But the other end >> >>cannot know that. >> >> >> >> The paragraph in the draft discussing the "entire Adj-RIB-Out" >> >>defines that to be the entries present "at the start of the route >> >>refresh operation", and observes that these comprise both reachable >> >>and unreachable routes. [An "of" after "comprise" sets teeth on edge, >> >>BTW.] I'm really not sure what this paragraph is trying to tell me. >> >> The reference to unreachable routes appears to suggest that pending >> >>withdraws should be sent as part of the refresh -- so not left to the >> >>EoRR to implement at the end. The point at which the EoRR is sent is >> >>defined such that it excludes any Adj-RIB-Out entries added after the >> >>route-refresh started, but includes any which are changed during the >> >>process. It seems reasonable to delay any brand new reachable >> >>prefixes until after all previously announced ones have been refreshed >> >>and the EoRR sent -- if that's the intent here. Changes which occur >> >>before the refresh gets to a given entry are pretty naturally swept up >> >>by the refresh. Changes which occur after the refresh has gone past, >> >>could/should be deferred to after the EoRR ? Does it make a >> >>difference if the change is a withdraw ? (Of course MRAI may kick in >> here. Ah. >> >>MRAI and route-refresh, there's a topic !) >> >> >> >> I think the essence of the rule is that the EoRR should be sent once >> >>all prefixes previously advertised to the peer as reachable have been >> >>refreshed, ie announced or withdrawn (at least) once. Or, perhaps >> >>more strictly, not *before* those prefixes have *all* been announced >> >>once -- given that the EoRR will promptly bang un-advertised stuff on >> the head. >> >>Even more strictly perhaps: not send EoRR *before* any withdraws >> >>implied by it are required or desirable. >> >> >> >> Depending on the implementation, a given sender may or may not be >> >>able to determine the minimum set of updates required before sending >> EoRR. >> >> >> >> If the refresh operation takes a long time, there may be good >> >>routeing reasons to arrange for some route changes to be sent to the >> peer "early" >> >>-- that is to send announcements which do not contribute to the >> >>refresh, but which are important enough to warrant delaying the end of >> >>the refresh. That could be a matter for recommendation(s) in the >> standard. >> >> >> >> NB: given that the timing of the EoRR is tied to the state of the >> >>Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. At >> >>the beginning of the initial update, the Restarting and Receiving >> >>speakers have: >> >> >> >> Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out >> >> >> >> Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In >> >> >> >> Now suppose (bonkers or otherwise) the receiving speaker sends an RRQ >> >>part way through the initial update. The restarting speaker responds >> >>with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specification. >> >> The receiving speaker sees the EoRR, and flushes stale. >> >>Unfortunately, if the restarting speaker has not yet fully populated >> >>its Adj-RIB-Out, then many further routes will be sent before the EoR >> >>falls due -- but the receiving speaker has already flushed their tiny >> >>posteriors :-( >> >> >> >> I am coming to the view that route-refresh during a Graceful Restart >> >>initial update is a horse of a different colour altogether. >> >> >> >> [So the assumption that EoRR and EoR are triggered by the same thing >> >>was completely wrong, and I apologise for it.] >> >> >> >> Chris >> >> >> >> _______________________________________________ >> >> 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 >> >> >> >> >> >> _________________________________________________________________________________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. >> Thank you. >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> >> > --bcaec51827b81bb97c04f11ddb23 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
When the session comes up after let's sa= y peer up there is no stale routes .. are there ? So the whole point of GR = is not to kill the routes before timeout and lack of new complete table fro= m a peer followed by EOR. 

Perhaps we have different cases in mi= nd ....

r.


On Wed, Jan 29, 2014 at 4:43 PM, Jakob Heitz= <jakob.heitz@ericsson.com> wrote:
If you kill a session doing GR, it kills all the stale routes. It'= s a bad thing.

--
Jakob Heitz.


On Jan 29, 2014, at 7:31 AM, "Robert Raszuk" <robert@raszuk.net> wrote:

Hi Jakob,

I thought we are mostly talking about initial time period after the session= is established and peer did not send EOR yet. So perhaps session reset wit= h right error is not that bad thing to do - if for nothing else then to sig= nal to the peer that his sequence is wrong ?

Or maybe we should do such things in BGP Diagnostic Message ?

Best,
R.




On Wed, Jan 29, 2014 at 4:17 PM, Jakob Heitz <jakob.hei= tz@ericsson.com> wrote:
I don't think these minor errors are worth killing a session (and = all the other routes) for.
Get a BoRR, mark stale.
Get an EoRR or EoR, delete stale.
If you get two BoRR in a row, it just means the sender decided to abor= t a refresh and start a new one.
If in doubt, send another refresh request. You'll get another BoRR= in response, so don't overdo it.

--
Jakob Heitz.


On Jan 29, 2014, at 1:51 AM, "bruno.decraene@orange.com" <bruno.decraene@orange.co= m> wrote:

Hi all,

 

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Wednesday, January 29, 2014 10:15 AM
To: Dongjie (Jimmy)
Cc: Keyur Patel (keyupate); idr@ietf.org
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refre= sh

 

= Hi Jimmy and all,

=  

= I think Enke and Keyur's proposed text with help from Jakob makes the b= ehavior simplified and deterministic to hold on BoRR till first EoR is seen= .

=  

= IMHO it should be also spelled out what is the expected sequence error hand= ling here

 

[Bruno] +1= .  And taking into account possible interaction with draft-ietf-idr-bg= p-gr-notification

&nb= sp;

BTW:=

“Whe= n the BGP speaker detects an error while processing a ROUTE-REFRESH message= with a non-zero "Message Subtype" field, it MUST send a NOTIFICA= TION message with Error Code "ROUTE-REFRESH Message Error".”=

&nb= sp;

Seems a pr= iori not inline with the recommendation from draft-ietf-grow-ops-reqs-for-b= gp-error-handling (which is to limit the consequences of error handling). Are we sure that no error condition could be handled in a more = friendly way? (e.g. if BoRR is not sent following a “normal route ref= resh request” or if 2 BoRR are sent consecutively…)<= /u>

&nb= sp;

Thanks,=

Regards,

Bruno

&nb= sp;

&nb= sp;

... I think not following &= quot;MUST NOT" shall implicitly result in entire session drop and comp= lete restart ? Any error code ?

=  

= Best,
R.

=  

 <= /p>

On Wed, Jan 29, 2014 at 9:22 AM, Dongjie (Jimmy) <= ;jie.dong@huawei.c= om> wrote:

Hi Robert,

 

Agree that= in these cases the RRQ cannot be ignored, so postpone may be a better choi= ce.

 

While IMO = stop the initial update and start over may delay the initial convergence, a= nd as you said  it also relates to update group processing. What do you think about the new text provided by Keyur? <= /u>

 

Best regards,

Jie

 

From: rraszuk@gmail.com [mailto:rraszuk@gm= ail.com] On Behalf Of Robert Raszuk
Sent: Sunday, January 26, 2014 11:03 PM
To: Dongjie (Jimmy)
Cc: Keyur Patel (keyupate); Jakob Heitz; idr@ietf.org


Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refre= sh

 

Hi Jie,

 

I think it actually very easy to say that initial update can= not ever guarantee that RRQ received during its sending may meet the peer&= #39;s need.

 

Example 1:

 

SAFI 128 - During receiving initial update from RR to PE new= VRF got added with new RT import. Unfortunately those updates received wit= hin initial update were already dropped as not interesting by the PE. RR must resend full table after completed initial update. (Of c= ourse this is the case where there is no RTC and that's why RTC helps a= lot here by incremental nature). 

 

Example 2: 

 

SAFI 1 - Operator has modified inbound policy on EBGP peer d= uring processing of incoming updates and those originally were dropped. No = soft reconfig in set. 

 

Conclusion:

 

RRQ can not ever be ignored. Sure they can be delayed or bat= ched (case of multiple peers within the same update/peer group) sending nea= r RRQs (cluster of PEs got provisioned from central management station). But as Keyur already mentioned those are rather stand= ard local implementation optimizations. 

 

Question:

 

Does it maybe make sense to stop initial update when receivi= ng RRQ from a peer and start over ? Of course if peer is part of large upda= te group it would have to be removed dynamically from it so other members are not delayed. In any case I think this does no= t impact the spec but the implementation.

 

Cheers,
R.

 

 

 

On Sun, Jan 26, 2014 at 7:13 PM= , Dongjie (Jimmy) <jie.dong@huawei.com> wrote:

Hi Keyur, Jakob,

Agree that "postpone" may be better. The point is we could avoid = the complicated cases/considerations of performing route refresh during ini= tial update:)

For "ignore", I was thinking of scenarios in which the route refr= esh requirement may already be met by the initial update, while I'd adm= it it is hard to say...



Best regards,
Jie

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

From: Keyur Patel (keyupate) [m= ailto:keyupate@cisc= o.com]
Sent: Sunday, January 26, 2014 8:30 PM
To: Jakob Heitz; Dongjie (Jimmy)
Cc: idr@ietf.org
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Jie,

I agree with Jakob. You could make it *an implementation behavior* to postp= one the route refresh reply.


Regards,
Keyur

On 1/26/14 1:29 AM, "Jakob Heitz" <jakob.heitz@ericsson.com> wrote:<= br>
>You can definitely not ignore it, but you could postpone it.
>
>--
>Jakob Heitz.
>
>> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" <jie.dong@huawei.com>
>>wrote:
>>
>> After reading the analyses in this thread, my personal feeling is<= br> >>maybe we should avoid the interleaving between GR initial update an= d
>>route refresh/enhanced route refresh, since the initial update is j= ust
>>sending the whole Adj-RIB-Out, there is no obvious advantage to sta= rt
>>a route refresh/enhance route refresh during it. So a speaker shoul= d
>>ignore the RRQ received during the initial update. Thoughts?
>>
>> Best regards,
>> Jie
>>
>> -----Original Message-----
>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz
>> Sent: Saturday, January 25, 2014 10:48 PM
>> To: Chris Hall; = idr@ietf.org
>> Subject: Re: [Idr] WG LC for
>> draft-ietf-idr-bgp-enhanced-route-refresh
>>
>> RFCs are written for coders "practiced" in the art"= .
>> If anyone sends an EoRR before the adj-RIB-out is fully populated,=
>>then it's a BUG.
>> This does not need to be said.
>>
>> Personally, I believe a route refresh request should not be honore= d
>>until GR is complete.
>> Also, I don't believe a timer for the receipt of EoRR is neces= sary,
>>because the EoRR is guaranteed.
>> Guaranteed means "unless the session drops first".
>> --
>>
>> Jakob Heitz.
>>
>> ________________________________________
>> From: Chris Hall [chris.hall@highwayman.com]
>> Sent: Saturday, 25 January 2014 11:27 AM
>> To: idr@ietf.org=
>> Cc: Jakob Heitz
>> Subject: RE: [Idr] WG LC for
>> draft-ietf-idr-bgp-enhanced-route-refresh
>>
>> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37):
>> ...
>>> Silence means don't do it.
>>
>> Hmmm.... as a principle I'm more comfortable with "that w= hich isn't
>>prohibited is permitted"....
>>
>>> You would definitely NOT want BoRR to flush old stales.
>>
>> ....but, given the definite requirement, and given that the curren= t
>>precedent for "marking stale" does flush old stale, then = a few words
>>for the avoidance of doubt ?
>>
>>> Restarting the timer might be a good idea.
>>
>> I dunno... a route which remains stale for "a long time"= is, of
>>course, a candidate for being withdrawn: so having started a timer = the
>>first time things are set stale, I would avoid extending that -- at=
>>least for Graceful Restart, where the whole withdraw thing has been= "on-hold"
>>since the last session failed.  For route-refresh I guess ther= e's more
>>of a presumption that stale routes will be refreshed sooner or late= r,
>>and in the meantime they remain good.  So if the route-refresh= is
>>(repeatedly) restarted for some reason, perhaps it is more reasonab= le
>>to extend the flush deadline -- but avoid doing this indefinitely ?=
>>
>> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I ha= ve
>>built in Quagga prioritise route changes (pending changes and any t= hat
>>occur during the refresh) over refresh updates.  This makes it= more
>>likely that remaining stale routes are still good.  But the ot= her end
>>cannot know that.
>>
>> The paragraph in the draft discussing the "entire Adj-RIB-Out= "
>>defines that to be the entries present "at the start of the ro= ute
>>refresh operation", and observes that these comprise both reac= hable
>>and unreachable routes.  [An "of" after "compri= se" sets teeth on edge,
>>BTW.]  I'm really not sure what this paragraph is trying t= o tell me.
>> The reference to unreachable routes appears to suggest that pendin= g
>>withdraws should be sent as part of the refresh -- so not left to t= he
>>EoRR to implement at the end.  The point at which the EoRR is = sent is
>>defined such that it excludes any Adj-RIB-Out entries added after t= he
>>route-refresh started, but includes any which are changed during th= e
>>process.  It seems reasonable to delay any brand new reachable=
>>prefixes until after all previously announced ones have been refres= hed
>>and the EoRR sent -- if that's the intent here.  Changes w= hich occur
>>before the refresh gets to a given entry are pretty naturally swept= up
>>by the refresh.  Changes which occur after the refresh has gon= e past,
>>could/should be deferred to after the EoRR ?  Does it make a >>difference if the change is a withdraw ?  (Of course MRAI may = kick in here.  Ah.
>>MRAI and route-refresh, there's a topic !)
>>
>> I think the essence of the rule is that the EoRR should be sent on= ce
>>all prefixes previously advertised to the peer as reachable have be= en
>>refreshed, ie announced or withdrawn (at least) once.  Or, per= haps
>>more strictly, not *before* those prefixes have *all* been announce= d
>>once -- given that the EoRR will promptly bang un-advertised stuff = on the head.
>>Even more strictly perhaps: not send EoRR *before* any withdraws >>implied by it are required or desirable.
>>
>> Depending on the implementation, a given sender may or may not be<= br> >>able to determine the minimum set of updates required before sendin= g EoRR.
>>
>> If the refresh operation takes a long time, there may be good
>>routeing reasons to arrange for some route changes to be sent to th= e peer "early"
>>-- that is to send announcements which do not contribute to the
>>refresh, but which are important enough to warrant delaying the end= of
>>the refresh.  That could be a matter for recommendation(s) in = the standard.
>>
>> NB: given that the timing of the EoRR is tied to the state of the<= br> >>Adj-RIB-Out, I'm not sure about the Graceful Restart assumption= s.  At
>>the beginning of the initial update, the Restarting and Receiving >>speakers have:
>>
>>  Restarting:  Empty Adj-RIB-In   Empty Adj-RIB-Out<= br> >>
>>  Receiving:   Empty Adj-RIB-Out  Stale Adj-RIB-In >>
>> Now suppose (bonkers or otherwise) the receiving speaker sends an = RRQ
>>part way through the initial update.  The restarting speaker r= esponds
>>with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specifica= tion.
>> The receiving speaker sees the EoRR, and flushes stale.
>>Unfortunately, if the restarting speaker has not yet fully populate= d
>>its Adj-RIB-Out, then many further routes will be sent before the E= oR
>>falls due -- but the receiving speaker has already flushed their ti= ny
>>posteriors :-(
>>
>> I am coming to the view that route-refresh during a Graceful Resta= rt
>>initial update is a horse of a different colour altogether.
>>
>> [So the assumption that EoRR and EoR are triggered by the same thi= ng
>>was completely wrong, and I apologise for it.]
>>
>> Chris
>>
>> _______________________________________________
>> 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
htt= ps://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 message=
s electroniques etant susceptibles d'alteration,
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 authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr


--bcaec51827b81bb97c04f11ddb23-- From bruno.decraene@orange.com Wed Jan 29 07:54:07 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84AA1A024E for ; Wed, 29 Jan 2014 07:54:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 433ULRQTdYdU for ; Wed, 29 Jan 2014 07:54:04 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 129BF1A0280 for ; Wed, 29 Jan 2014 07:54:03 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 019691B8921; Wed, 29 Jan 2014 16:54:00 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id D18EF3840A2; Wed, 29 Jan 2014 16:53:59 +0100 (CET) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Wed, 29 Jan 2014 16:53:59 +0100 From: To: Robert Raszuk , Jakob Heitz Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPF5Kd3MXmo8KxoESEhujQiGLM/ZqRMOhAgAGfMAD//7gu+4AAX1gA//+1BTCAAHhgAP//sQGgAA5+ToAABygAoAAmsOcAAAoIr7AAJlf4AP//r6/0gAEnPAD//8BcWoAA2iqAgAAMEwCAAB6LgIAD81WAgAAOsoCAAAoOAIAAB0uL///zW4D//+sacA== Date: Wed, 29 Jan 2014 15:53:59 +0000 Message-ID: <29271_1391010839_52E92417_29271_18787_1_53C29892C857584299CBF5D05346208A070E002C@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <00AB3F7F-5E33-4533-96C7-E7F75A3E76CB@ericsson.com> <76CD132C3ADEF848BD84D028D243C927335C435C@nkgeml512-mbx.china.huawei.com> <76CD132C3ADEF848BD84D028D243C927335C6B18@nkgeml512-mbx.china.huawei.com> <6650_1390989061_52E8CF05_6650_399_1_53C29892C857584299CBF5D05346208A070DFED8@PEXCVZYM11.corporate.adroot.infra.ftgroup> <0C0CE57B-CA57-471D-BE3C-8B5F380BE087@ericsson.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.29.140915 Cc: "Keyur Patel \(keyupate\)" , "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 15:54:08 -0000 Hi Robert, all > if for nothing else then to signal to the peer that his sequence is wron= g ? Let's not send a NOTIFICATION just for logging purpose. This seems overkill= to me. For iBGP sessions, logging the error is probably enough. For eBGP sessions, a BGP diagnostic message may be a good channel. However, the requirement for error signaling seems lower for bgp-enhanced-r= oute-refresh compared to idr-error-handling (where the errors may be more s= ignificant from routing correctness point of view) Regards, Bruno >From: Robert Raszuk >Sent: Wednesday, January 29, 2014 4:32 PM > >Hi Jakob, > >I thought we are mostly talking about initial time period after the session >is established and peer did not send EOR yet. So perhaps session reset with >right error is not that bad thing to do - if for nothing else then to sign= al >to the peer that his sequence is wrong ? > >Or maybe we should do such things in BGP Diagnostic Message ? > >Best, >R. > > > >On Wed, Jan 29, 2014 at 4:17 PM, Jakob Heitz >wrote: >I don't think these minor errors are worth killing a session (and all the >other routes) for. >Get a BoRR, mark stale. >Get an EoRR or EoR, delete stale. >If you get two BoRR in a row, it just means the sender decided to abort a >refresh and start a new one. >If in doubt, send another refresh request. You'll get another BoRR in >response, so don't overdo it. > >-- >Jakob Heitz. > > >On Jan 29, 2014, at 1:51 AM, "bruno.decraene@orange.com" > wrote: >Hi all, > > >From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk >Sent: Wednesday, January 29, 2014 10:15 AM >To: Dongjie (Jimmy) >Cc: Keyur Patel (keyupate); idr@ietf.org >Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh > >Hi Jimmy and all, > >I think Enke and Keyur's proposed text with help from Jakob makes the >behavior simplified and deterministic to hold on BoRR till first EoR is >seen. > >IMHO it should be also spelled out what is the expected sequence error >handling here > >[Bruno] +1. =A0And taking into account possible interaction with draft-iet= f- >idr-bgp-gr-notification > >BTW: >"When the BGP speaker detects an error while processing a ROUTE-REFRESH >message with a non-zero "Message Subtype" field, it MUST send a NOTIFICATI= ON >message with Error Code "ROUTE-REFRESH Message Error"." > >Seems a priori not inline with the recommendation from draft-ietf-grow-ops- >reqs-for-bgp-error-handling (which is to limit the consequences of error >handling). Are we sure that no error condition could be handled in a more >friendly way? (e.g. if BoRR is not sent following a "normal route refresh >request" or if 2 BoRR are sent consecutively.) > >Thanks, >Regards, >Bruno > > >... I think not following "MUST NOT" shall implicitly result in entire >session drop and complete restart ? Any error code ? > >Best, >R. > > >On Wed, Jan 29, 2014 at 9:22 AM, Dongjie (Jimmy) >wrote: >Hi Robert, > >Agree that in these cases the RRQ cannot be ignored, so postpone may be a >better choice. > >While IMO stop the initial update and start over may delay the initial >convergence, and as you said =A0it also relates to update group processing. >What do you think about the new text provided by Keyur? > >Best regards, >Jie > >From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert >Raszuk >Sent: Sunday, January 26, 2014 11:03 PM >To: Dongjie (Jimmy) >Cc: Keyur Patel (keyupate); Jakob Heitz; idr@ietf.org > >Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh > >Hi Jie, > >I think it actually very easy to say that initial update can not ever >guarantee that RRQ received during its sending may meet the peer's need. > >Example 1: > >SAFI 128 - During receiving initial update from RR to PE new VRF got added >with new RT import. Unfortunately those updates received within initial >update were already dropped as not interesting by the PE. RR must resend >full table after completed initial update. (Of course this is the case whe= re >there is no RTC and that's why RTC helps a lot here by incremental nature). > >Example 2: > >SAFI 1 - Operator has modified inbound policy on EBGP peer during processi= ng >of incoming updates and those originally were dropped. No soft reconfig in >set. > >Conclusion: > >RRQ can not ever be ignored. Sure they can be delayed or batched (case of >multiple peers within the same update/peer group) sending near RRQs (clust= er >of PEs got provisioned from central management station). But as Keyur >already mentioned those are rather standard local implementation >optimizations. > >Question: > >Does it maybe make sense to stop initial update when receiving RRQ from a >peer and start over ? Of course if peer is part of large update group it >would have to be removed dynamically from it so other members are not >delayed. In any case I think this does not impact the spec but the >implementation. > >Cheers, >R. > > > >On Sun, Jan 26, 2014 at 7:13 PM, Dongjie (Jimmy) >wrote: >Hi Keyur, Jakob, > >Agree that "postpone" may be better. The point is we could avoid the >complicated cases/considerations of performing route refresh during initial >update:) > >For "ignore", I was thinking of scenarios in which the route refresh >requirement may already be met by the initial update, while I'd admit it is >hard to say... > > >Best regards, >Jie > >-----Original Message----- >From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] >Sent: Sunday, January 26, 2014 8:30 PM >To: Jakob Heitz; Dongjie (Jimmy) >Cc: idr@ietf.org >Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh > >Jie, > >I agree with Jakob. You could make it *an implementation behavior* to >postpone the route refresh reply. > > >Regards, >Keyur > >On 1/26/14 1:29 AM, "Jakob Heitz" wrote: > >>You can definitely not ignore it, but you could postpone it. >> >>-- >>Jakob Heitz. >> >>> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" >>>wrote: >>> >>> After reading the analyses in this thread, my personal feeling is >>>maybe we should avoid the interleaving between GR initial update and >>>route refresh/enhanced route refresh, since the initial update is just >>>sending the whole Adj-RIB-Out, there is no obvious advantage to start >>>a route refresh/enhance route refresh during it. So a speaker should >>>ignore the RRQ received during the initial update. Thoughts? >>> >>> Best regards, >>> Jie >>> >>> -----Original Message----- >>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz >>> Sent: Saturday, January 25, 2014 10:48 PM >>> To: Chris Hall; idr@ietf.org >>> Subject: Re: [Idr] WG LC for >>> draft-ietf-idr-bgp-enhanced-route-refresh >>> >>> RFCs are written for coders "practiced" in the art". >>> If anyone sends an EoRR before the adj-RIB-out is fully populated, >>>then it's a BUG. >>> This does not need to be said. >>> >>> Personally, I believe a route refresh request should not be honored >>>until GR is complete. >>> Also, I don't believe a timer for the receipt of EoRR is necessary, >>>because the EoRR is guaranteed. >>> Guaranteed means "unless the session drops first". >>> -- >>> >>> Jakob Heitz. >>> >>> ________________________________________ >>> From: Chris Hall [chris.hall@highwayman.com] >>> Sent: Saturday, 25 January 2014 11:27 AM >>> To: idr@ietf.org >>> Cc: Jakob Heitz >>> Subject: RE: [Idr] WG LC for >>> draft-ietf-idr-bgp-enhanced-route-refresh >>> >>> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): >>> ... >>>> Silence means don't do it. >>> >>> Hmmm.... as a principle I'm more comfortable with "that which isn't >>>prohibited is permitted".... >>> >>>> You would definitely NOT want BoRR to flush old stales. >>> >>> ....but, given the definite requirement, and given that the current >>>precedent for "marking stale" does flush old stale, then a few words >>>for the avoidance of doubt ? >>> >>>> Restarting the timer might be a good idea. >>> >>> I dunno... a route which remains stale for "a long time" is, of >>>course, a candidate for being withdrawn: so having started a timer the >>>first time things are set stale, I would avoid extending that -- at >>>least for Graceful Restart, where the whole withdraw thing has been "on- >hold" >>>since the last session failed. =A0For route-refresh I guess there's more >>>of a presumption that stale routes will be refreshed sooner or later, >>>and in the meantime they remain good. =A0So if the route-refresh is >>>(repeatedly) restarted for some reason, perhaps it is more reasonable >>>to extend the flush deadline -- but avoid doing this indefinitely ? >>> >>> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I have >>>built in Quagga prioritise route changes (pending changes and any that >>>occur during the refresh) over refresh updates. =A0This makes it more >>>likely that remaining stale routes are still good. =A0But the other end >>>cannot know that. >>> >>> The paragraph in the draft discussing the "entire Adj-RIB-Out" >>>defines that to be the entries present "at the start of the route >>>refresh operation", and observes that these comprise both reachable >>>and unreachable routes. =A0[An "of" after "comprise" sets teeth on edge, >>>BTW.] =A0I'm really not sure what this paragraph is trying to tell me. >>> The reference to unreachable routes appears to suggest that pending >>>withdraws should be sent as part of the refresh -- so not left to the >>>EoRR to implement at the end. =A0The point at which the EoRR is sent is >>>defined such that it excludes any Adj-RIB-Out entries added after the >>>route-refresh started, but includes any which are changed during the >>>process. =A0It seems reasonable to delay any brand new reachable >>>prefixes until after all previously announced ones have been refreshed >>>and the EoRR sent -- if that's the intent here. =A0Changes which occur >>>before the refresh gets to a given entry are pretty naturally swept up >>>by the refresh. =A0Changes which occur after the refresh has gone past, >>>could/should be deferred to after the EoRR ? =A0Does it make a >>>difference if the change is a withdraw ? =A0(Of course MRAI may kick in >here. =A0Ah. >>>MRAI and route-refresh, there's a topic !) >>> >>> I think the essence of the rule is that the EoRR should be sent once >>>all prefixes previously advertised to the peer as reachable have been >>>refreshed, ie announced or withdrawn (at least) once. =A0Or, perhaps >>>more strictly, not *before* those prefixes have *all* been announced >>>once -- given that the EoRR will promptly bang un-advertised stuff on the >head. >>>Even more strictly perhaps: not send EoRR *before* any withdraws >>>implied by it are required or desirable. >>> >>> Depending on the implementation, a given sender may or may not be >>>able to determine the minimum set of updates required before sending EoR= R. >>> >>> If the refresh operation takes a long time, there may be good >>>routeing reasons to arrange for some route changes to be sent to the peer >"early" >>>-- that is to send announcements which do not contribute to the >>>refresh, but which are important enough to warrant delaying the end of >>>the refresh. =A0That could be a matter for recommendation(s) in the >standard. >>> >>> NB: given that the timing of the EoRR is tied to the state of the >>>Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. =A0At >>>the beginning of the initial update, the Restarting and Receiving >>>speakers have: >>> >>> =A0Restarting: =A0Empty Adj-RIB-In =A0 Empty Adj-RIB-Out >>> >>> =A0Receiving: =A0 Empty Adj-RIB-Out =A0Stale Adj-RIB-In >>> >>> Now suppose (bonkers or otherwise) the receiving speaker sends an RRQ >>>part way through the initial update. =A0The restarting speaker responds >>>with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specification. >>> The receiving speaker sees the EoRR, and flushes stale. >>>Unfortunately, if the restarting speaker has not yet fully populated >>>its Adj-RIB-Out, then many further routes will be sent before the EoR >>>falls due -- but the receiving speaker has already flushed their tiny >>>posteriors :-( >>> >>> I am coming to the view that route-refresh during a Graceful Restart >>>initial update is a horse of a different colour altogether. >>> >>> [So the assumption that EoRR and EoR are triggered by the same thing >>>was completely wrong, and I apologise for it.] >>> >>> Chris >>> >>> _______________________________________________ >>> 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 > > >__________________________________________________________________________= __ >_____________________________________________ > >Ce message et ses pieces jointes peuvent contenir des informations >confidentielles ou privilegiees et ne doivent donc >pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu >ce message par erreur, veuillez le signaler >a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >electroniques etant susceptibles d'alteration, >Orange decline toute responsabilite si ce message a ete altere, deforme ou >falsifie. Merci. > >This message and its attachments may contain confidential or privileged >information that may be protected by law; >they should not be distributed, used or copied without authorisation. >If you have received this email in error, please notify the sender and >delete this message and its attachments. >As emails may be altered, Orange is not liable for messages that have been >modified, changed or falsified. >Thank you. >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ 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, 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 authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From jakob.heitz@ericsson.com Wed Jan 29 07:54:48 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6396C1A0216 for ; Wed, 29 Jan 2014 07:54:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwebhetPPxLe for ; Wed, 29 Jan 2014 07:54:42 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 904EF1A0207 for ; Wed, 29 Jan 2014 07:54:42 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-03-52e9243fb750 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id B0.C0.11484.F3429E25; Wed, 29 Jan 2014 16:54:40 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0387.000; Wed, 29 Jan 2014 10:54:38 -0500 From: Jakob Heitz To: Robert Raszuk Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPF5KdKHMolEg8TF26AxOKep0T6JqRMOhAgAGfMAD//7gu+4AAX1gA//+1BTCAAHhgAP//sQGgAA5+ToAABygAoAAmsOcAAAoIr7AAJlf4AP//r6/0gAEnPAD//8BcWoAA2iqAgAAMEwCAAB6LgIAD81WAgAAOsoCAAAoOAIAAB0uLgABX8ID//6+RJoAAVMGA//+uOy0= Date: Wed, 29 Jan 2014 15:54:38 +0000 Message-ID: <3DD27E91-5FE2-4879-B03E-7C25FB66D4E5@ericsson.com> References: <00AB3F7F-5E33-4533-96C7-E7F75A3E76CB@ericsson.com> <76CD132C3ADEF848BD84D028D243C927335C435C@nkgeml512-mbx.china.huawei.com> <76CD132C3ADEF848BD84D028D243C927335C6B18@nkgeml512-mbx.china.huawei.com> <6650_1390989061_52E8CF05_6650_399_1_53C29892C857584299CBF5D05346208A070DFED8@PEXCVZYM11.corporate.adroot.infra.ftgroup> <0C0CE57B-CA57-471D-BE3C-8B5F380BE087@ericsson.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_3DD27E915FE24879B03E7C25FB66D4E5ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyuXSPt66Dyssgg0PzeS1+7JjDbPHq9jMm i8at59ksmhY2MTuweEz5vZHVY8mSn0weLc9Osnns3riAKYAlissmJTUnsyy1SN8ugSvj9tvT 7AVvPjJV3J38hL2B8eJepi5GTg4JAROJCRuOMELYYhIX7q1n62Lk4hASOMIosfHQUVYIZzmj xIPdh8Gq2AR0JL5d72IGsUUEVCU6TzxiBiliFuhmlDi7opENJCEs4CbxatJydogid4mWH5PA ikQEbjFKXLn3jAUkwQLU3bKvEWwSr4C9xPkFvYwQ6/6xSmzd3AB2IKdAoMSiGzPBpjICHfj9 1BqwOLOAuMStJ/OhnhCQWLLnPDOELSrx8vE/VoiaZInTU/YzQSwQlDg58wnLBEaRWUjaZyEp m4WkDCJuIPH+3HxmCFtbYtnC11C2vsTGL2cZkcUXMLKvYuQoLU4ty003MtzECIy4YxJsjjsY F3yyPMQozcGiJM775a1zkJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbG1PhFbW6nj3Yw7fVy cWWec+2fTvXEVI5fGpsMQ9kXuFsHVzgYvIyx3HH1z9ZuvdJwjZNsGim3Jumumb0k5uj65y8n 5Qt9E7krbZx0Q+nYqUeTlzf7HDN9OsX+2LzTz6JOTm90PXbKIrvxNpfXTu2NfnO3s8pp+55i 3jpPdOG+KXlHpeYvS9y0T4mlOCPRUIu5qDgRAP9682aGAgAA Cc: "Keyur Patel \(keyupate\)" , "bruno.decraene@orange.com" , "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 15:54:48 -0000 --_000_3DD27E915FE24879B03E7C25FB66D4E5ericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The case I have in mind: I restarted. You retained my routes and marked them stale. You send some sequence of BoRR and EoRR that I consider an error. I send you NOTIFICATION. You delete all my stale routes. -- Jakob Heitz. On Jan 29, 2014, at 7:47 AM, "Robert Raszuk" > wrote: When the session comes up after let's say peer up there is no stale routes = .. are there ? So the whole point of GR is not to kill the routes before ti= meout and lack of new complete table from a peer followed by EOR. Perhaps we have different cases in mind .... r. On Wed, Jan 29, 2014 at 4:43 PM, Jakob Heitz > wrote: If you kill a session doing GR, it kills all the stale routes. It's a bad t= hing. -- Jakob Heitz. On Jan 29, 2014, at 7:31 AM, "Robert Raszuk" > wrote: Hi Jakob, I thought we are mostly talking about initial time period after the session= is established and peer did not send EOR yet. So perhaps session reset wit= h right error is not that bad thing to do - if for nothing else then to sig= nal to the peer that his sequence is wrong ? Or maybe we should do such things in BGP Diagnostic Message ? Best, R. On Wed, Jan 29, 2014 at 4:17 PM, Jakob Heitz > wrote: I don't think these minor errors are worth killing a session (and all the o= ther routes) for. Get a BoRR, mark stale. Get an EoRR or EoR, delete stale. If you get two BoRR in a row, it just means the sender decided to abort a r= efresh and start a new one. If in doubt, send another refresh request. You'll get another BoRR in respo= nse, so don't overdo it. -- Jakob Heitz. On Jan 29, 2014, at 1:51 AM, "bruno.decraene@orange.com" > wrote: Hi all, From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: Wednesday, January 29, 2014 10:15 AM To: Dongjie (Jimmy) Cc: Keyur Patel (keyupate); idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Jimmy and all, I think Enke and Keyur's proposed text with help from Jakob makes the behav= ior simplified and deterministic to hold on BoRR till first EoR is seen. IMHO it should be also spelled out what is the expected sequence error hand= ling here [Bruno] +1. And taking into account possible interaction with draft-ietf-i= dr-bgp-gr-notification BTW: =93When the BGP speaker detects an error while processing a ROUTE-REFRESH m= essage with a non-zero "Message Subtype" field, it MUST send a NOTIFICATION= message with Error Code "ROUTE-REFRESH Message Error".=94 Seems a priori not inline with the recommendation from draft-ietf-grow-ops-= reqs-for-bgp-error-handling (which is to limit the consequences of error ha= ndling). Are we sure that no error condition could be handled in a more fri= endly way? (e.g. if BoRR is not sent following a =93normal route refresh re= quest=94 or if 2 BoRR are sent consecutively=85) Thanks, Regards, Bruno ... I think not following "MUST NOT" shall implicitly result in entire sess= ion drop and complete restart ? Any error code ? Best, R. On Wed, Jan 29, 2014 at 9:22 AM, Dongjie (Jimmy) > wrote: Hi Robert, Agree that in these cases the RRQ cannot be ignored, so postpone may be a b= etter choice. While IMO stop the initial update and start over may delay the initial conv= ergence, and as you said it also relates to update group processing. What = do you think about the new text provided by Keyur? Best regards, Jie From: rraszuk@gmail.com [mailto:rraszuk@gmail.com= ] On Behalf Of Robert Raszuk Sent: Sunday, January 26, 2014 11:03 PM To: Dongjie (Jimmy) Cc: Keyur Patel (keyupate); Jakob Heitz; idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Jie, I think it actually very easy to say that initial update can not ever guara= ntee that RRQ received during its sending may meet the peer's need. Example 1: SAFI 128 - During receiving initial update from RR to PE new VRF got added = with new RT import. Unfortunately those updates received within initial upd= ate were already dropped as not interesting by the PE. RR must resend full = table after completed initial update. (Of course this is the case where the= re is no RTC and that's why RTC helps a lot here by incremental nature). Example 2: SAFI 1 - Operator has modified inbound policy on EBGP peer during processin= g of incoming updates and those originally were dropped. No soft reconfig i= n set. Conclusion: RRQ can not ever be ignored. Sure they can be delayed or batched (case of m= ultiple peers within the same update/peer group) sending near RRQs (cluster= of PEs got provisioned from central management station). But as Keyur alre= ady mentioned those are rather standard local implementation optimizations. Question: Does it maybe make sense to stop initial update when receiving RRQ from a p= eer and start over ? Of course if peer is part of large update group it wou= ld have to be removed dynamically from it so other members are not delayed.= In any case I think this does not impact the spec but the implementation. Cheers, R. On Sun, Jan 26, 2014 at 7:13 PM, Dongjie (Jimmy) > wrote: Hi Keyur, Jakob, Agree that "postpone" may be better. The point is we could avoid the compli= cated cases/considerations of performing route refresh during initial updat= e:) For "ignore", I was thinking of scenarios in which the route refresh requir= ement may already be met by the initial update, while I'd admit it is hard = to say... Best regards, Jie -----Original Message----- From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] Sent: Sunday, January 26, 2014 8:30 PM To: Jakob Heitz; Dongjie (Jimmy) Cc: idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Jie, I agree with Jakob. You could make it *an implementation behavior* to postp= one the route refresh reply. Regards, Keyur On 1/26/14 1:29 AM, "Jakob Heitz" > wrote: >You can definitely not ignore it, but you could postpone it. > >-- >Jakob Heitz. > >> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" > >>wrote: >> >> After reading the analyses in this thread, my personal feeling is >>maybe we should avoid the interleaving between GR initial update and >>route refresh/enhanced route refresh, since the initial update is just >>sending the whole Adj-RIB-Out, there is no obvious advantage to start >>a route refresh/enhance route refresh during it. So a speaker should >>ignore the RRQ received during the initial update. Thoughts? >> >> Best regards, >> Jie >> >> -----Original Message----- >> From: Idr [mailto:idr-bounces@ietf.org] On = Behalf Of Jakob Heitz >> Sent: Saturday, January 25, 2014 10:48 PM >> To: Chris Hall; idr@ietf.org >> Subject: Re: [Idr] WG LC for >> draft-ietf-idr-bgp-enhanced-route-refresh >> >> RFCs are written for coders "practiced" in the art". >> If anyone sends an EoRR before the adj-RIB-out is fully populated, >>then it's a BUG. >> This does not need to be said. >> >> Personally, I believe a route refresh request should not be honored >>until GR is complete. >> Also, I don't believe a timer for the receipt of EoRR is necessary, >>because the EoRR is guaranteed. >> Guaranteed means "unless the session drops first". >> -- >> >> Jakob Heitz. >> >> ________________________________________ >> From: Chris Hall [chris.hall@highwayman.com] >> Sent: Saturday, 25 January 2014 11:27 AM >> To: idr@ietf.org >> Cc: Jakob Heitz >> Subject: RE: [Idr] WG LC for >> draft-ietf-idr-bgp-enhanced-route-refresh >> >> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): >> ... >>> Silence means don't do it. >> >> Hmmm.... as a principle I'm more comfortable with "that which isn't >>prohibited is permitted".... >> >>> You would definitely NOT want BoRR to flush old stales. >> >> ....but, given the definite requirement, and given that the current >>precedent for "marking stale" does flush old stale, then a few words >>for the avoidance of doubt ? >> >>> Restarting the timer might be a good idea. >> >> I dunno... a route which remains stale for "a long time" is, of >>course, a candidate for being withdrawn: so having started a timer the >>first time things are set stale, I would avoid extending that -- at >>least for Graceful Restart, where the whole withdraw thing has been "on-h= old" >>since the last session failed. For route-refresh I guess there's more >>of a presumption that stale routes will be refreshed sooner or later, >>and in the meantime they remain good. So if the route-refresh is >>(repeatedly) restarted for some reason, perhaps it is more reasonable >>to extend the flush deadline -- but avoid doing this indefinitely ? >> >> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I have >>built in Quagga prioritise route changes (pending changes and any that >>occur during the refresh) over refresh updates. This makes it more >>likely that remaining stale routes are still good. But the other end >>cannot know that. >> >> The paragraph in the draft discussing the "entire Adj-RIB-Out" >>defines that to be the entries present "at the start of the route >>refresh operation", and observes that these comprise both reachable >>and unreachable routes. [An "of" after "comprise" sets teeth on edge, >>BTW.] I'm really not sure what this paragraph is trying to tell me. >> The reference to unreachable routes appears to suggest that pending >>withdraws should be sent as part of the refresh -- so not left to the >>EoRR to implement at the end. The point at which the EoRR is sent is >>defined such that it excludes any Adj-RIB-Out entries added after the >>route-refresh started, but includes any which are changed during the >>process. It seems reasonable to delay any brand new reachable >>prefixes until after all previously announced ones have been refreshed >>and the EoRR sent -- if that's the intent here. Changes which occur >>before the refresh gets to a given entry are pretty naturally swept up >>by the refresh. Changes which occur after the refresh has gone past, >>could/should be deferred to after the EoRR ? Does it make a >>difference if the change is a withdraw ? (Of course MRAI may kick in her= e. Ah. >>MRAI and route-refresh, there's a topic !) >> >> I think the essence of the rule is that the EoRR should be sent once >>all prefixes previously advertised to the peer as reachable have been >>refreshed, ie announced or withdrawn (at least) once. Or, perhaps >>more strictly, not *before* those prefixes have *all* been announced >>once -- given that the EoRR will promptly bang un-advertised stuff on the= head. >>Even more strictly perhaps: not send EoRR *before* any withdraws >>implied by it are required or desirable. >> >> Depending on the implementation, a given sender may or may not be >>able to determine the minimum set of updates required before sending EoRR= . >> >> If the refresh operation takes a long time, there may be good >>routeing reasons to arrange for some route changes to be sent to the peer= "early" >>-- that is to send announcements which do not contribute to the >>refresh, but which are important enough to warrant delaying the end of >>the refresh. That could be a matter for recommendation(s) in the standar= d. >> >> NB: given that the timing of the EoRR is tied to the state of the >>Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. At >>the beginning of the initial update, the Restarting and Receiving >>speakers have: >> >> Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out >> >> Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In >> >> Now suppose (bonkers or otherwise) the receiving speaker sends an RRQ >>part way through the initial update. The restarting speaker responds >>with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specification. >> The receiving speaker sees the EoRR, and flushes stale. >>Unfortunately, if the restarting speaker has not yet fully populated >>its Adj-RIB-Out, then many further routes will be sent before the EoR >>falls due -- but the receiving speaker has already flushed their tiny >>posteriors :-( >> >> I am coming to the view that route-refresh during a Graceful Restart >>initial update is a horse of a different colour altogether. >> >> [So the assumption that EoRR and EoR are triggered by the same thing >>was completely wrong, and I apologise for it.] >> >> Chris >> >> _______________________________________________ >> 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 ___________________________________________________________________________= ______________________________________________ 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, 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 authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_3DD27E915FE24879B03E7C25FB66D4E5ericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
The case I have in mind:
I restarted. You retained my routes and marked them stale.
You send some sequence of BoRR and EoRR that I consider an error.
I send you NOTIFICATION.
You delete all my stale routes.

--
Jakob Heitz.


On Jan 29, 2014, at 7:47 AM, "Robert Raszuk" <robert@raszuk.net> wrote:

When the session comes up after let's say peer up there is no stale routes = .. are there ? So the whole point of GR is not to kill the routes before ti= meout and lack of new complete table from a peer followed by EOR. 

Perhaps we have different cases in mind ....

r.


On Wed, Jan 29, 2014 at 4:43 PM, Jakob Heitz <jakob.hei= tz@ericsson.com> wrote:
If you kill a session doing GR, it kills all the stale routes. It's a = bad thing.

--
Jakob Heitz.


On Jan 29, 2014, at 7:31 AM, "Robert Raszuk" <robert@raszuk.net> wrote:

Hi Jakob,

I thought we are mostly talking about initial time period after the session= is established and peer did not send EOR yet. So perhaps session reset wit= h right error is not that bad thing to do - if for nothing else then to sig= nal to the peer that his sequence is wrong ?

Or maybe we should do such things in BGP Diagnostic Message ?

Best,
R.




On Wed, Jan 29, 2014 at 4:17 PM, Jakob Heitz <jakob.hei= tz@ericsson.com> wrote:
I don't think these minor errors are worth killing a session (and all = the other routes) for.
Get a BoRR, mark stale.
Get an EoRR or EoR, delete stale.
If you get two BoRR in a row, it just means the sender decided to abor= t a refresh and start a new one.
If in doubt, send another refresh request. You'll get another BoRR in = response, so don't overdo it.

--
Jakob Heitz.


On Jan 29, 2014, at 1:51 AM, "bruno.decraene@orange.com" <bruno.decraene@orange.co= m> wrote:

Hi all,

 

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Wednesday, January 29, 2014 10:15 AM
To: Dongjie (Jimmy)
Cc: Keyur Patel (keyupate); idr@ietf.org
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refre= sh

 

= Hi Jimmy and all,

=  

= I think Enke and Keyur's proposed text with help from Jakob makes the behav= ior simplified and deterministic to hold on BoRR till first EoR is seen.=

=  

= IMHO it should be also spelled out what is the expected sequence error hand= ling here

 

[Bruno] &#= 43;1.  And taking into account possible interaction with draft-ietf-id= r-bgp-gr-notification

&nb= sp;

BTW:=

=93When th= e BGP speaker detects an error while processing a ROUTE-REFRESH message wit= h a non-zero "Message Subtype" field, it MUST send a NOTIFICATION message with Error Code "ROUTE-REFRESH Message Error".=94=

&nb= sp;

Seems a pr= iori not inline with the recommendation from draft-ietf-grow-ops-reqs-for-b= gp-error-handling (which is to limit the consequences of error handling). Are we sure that no error condition could be handled in a more = friendly way? (e.g. if BoRR is not sent following a =93normal route refresh= request=94 or if 2 BoRR are sent consecutively=85)

&nb= sp;

Thanks,=

Regards,

Bruno

&nb= sp;

&nb= sp;

... I think not following &= quot;MUST NOT" shall implicitly result in entire session drop and comp= lete restart ? Any error code ?

=  

= Best,
R.

=  

 <= /p>

On Wed, Jan 29, 2014 at 9:22 AM, Dongjie (Jimmy) <= ;jie.dong@huawei.c= om> wrote:

Hi Robert,

 

Agree that= in these cases the RRQ cannot be ignored, so postpone may be a better choi= ce.

 

While IMO = stop the initial update and start over may delay the initial convergence, a= nd as you said  it also relates to update group processing. What do you think about the new text provided by Keyur? <= /u>

 

Best regards,

Jie

 

From: rraszuk@gmail.com [mailto:rraszuk@gm= ail.com] On Behalf Of Robert Raszuk
Sent: Sunday, January 26, 2014 11:03 PM
To: Dongjie (Jimmy)
Cc: Keyur Patel (keyupate); Jakob Heitz; idr@ietf.org


Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refre= sh

 

Hi Jie,

 

I think it actually very easy to say that initial update can= not ever guarantee that RRQ received during its sending may meet the peer'= s need.

 

Example 1:

 

SAFI 128 - During receiving initial update from RR to PE new= VRF got added with new RT import. Unfortunately those updates received wit= hin initial update were already dropped as not interesting by the PE. RR must resend full table after completed initial update. (Of c= ourse this is the case where there is no RTC and that's why RTC helps a lot= here by incremental nature). 

 

Example 2: 

 

SAFI 1 - Operator has modified inbound policy on EBGP peer d= uring processing of incoming updates and those originally were dropped. No = soft reconfig in set. 

 

Conclusion:

 

RRQ can not ever be ignored. Sure they can be delayed or bat= ched (case of multiple peers within the same update/peer group) sending nea= r RRQs (cluster of PEs got provisioned from central management station). But as Keyur already mentioned those are rather stand= ard local implementation optimizations. 

 

Question:

 

Does it maybe make sense to stop initial update when receivi= ng RRQ from a peer and start over ? Of course if peer is part of large upda= te group it would have to be removed dynamically from it so other members are not delayed. In any case I think this does no= t impact the spec but the implementation.

 

Cheers,
R.

 

 

 

On Sun, Jan 26, 2014 at 7:13 PM= , Dongjie (Jimmy) <jie.dong@huawei.com> wrote:

Hi Keyur, Jakob,

Agree that "postpone" may be better. The point is we could avoid = the complicated cases/considerations of performing route refresh during ini= tial update:)

For "ignore", I was thinking of scenarios in which the route refr= esh requirement may already be met by the initial update, while I'd admit i= t is hard to say...



Best regards,
Jie

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

From: Keyur Patel (keyupate) [m= ailto:keyupate@cisc= o.com]
Sent: Sunday, January 26, 2014 8:30 PM
To: Jakob Heitz; Dongjie (Jimmy)
Cc: idr@ietf.org
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Jie,

I agree with Jakob. You could make it *an implementation behavior* to postp= one the route refresh reply.


Regards,
Keyur

On 1/26/14 1:29 AM, "Jakob Heitz" <jakob.heitz@ericsson.com> wrote:<= br>
>You can definitely not ignore it, but you could postpone it.
>
>--
>Jakob Heitz.
>
>> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" <jie.dong@huawei.com>
>>wrote:
>>
>> After reading the analyses in this thread, my personal feeling is<= br> >>maybe we should avoid the interleaving between GR initial update an= d
>>route refresh/enhanced route refresh, since the initial update is j= ust
>>sending the whole Adj-RIB-Out, there is no obvious advantage to sta= rt
>>a route refresh/enhance route refresh during it. So a speaker shoul= d
>>ignore the RRQ received during the initial update. Thoughts?
>>
>> Best regards,
>> Jie
>>
>> -----Original Message-----
>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz
>> Sent: Saturday, January 25, 2014 10:48 PM
>> To: Chris Hall; = idr@ietf.org
>> Subject: Re: [Idr] WG LC for
>> draft-ietf-idr-bgp-enhanced-route-refresh
>>
>> RFCs are written for coders "practiced" in the art"= .
>> If anyone sends an EoRR before the adj-RIB-out is fully populated,=
>>then it's a BUG.
>> This does not need to be said.
>>
>> Personally, I believe a route refresh request should not be honore= d
>>until GR is complete.
>> Also, I don't believe a timer for the receipt of EoRR is necessary= ,
>>because the EoRR is guaranteed.
>> Guaranteed means "unless the session drops first".
>> --
>>
>> Jakob Heitz.
>>
>> ________________________________________
>> From: Chris Hall [chris.hall@highwayman.com]
>> Sent: Saturday, 25 January 2014 11:27 AM
>> To: idr@ietf.org=
>> Cc: Jakob Heitz
>> Subject: RE: [Idr] WG LC for
>> draft-ietf-idr-bgp-enhanced-route-refresh
>>
>> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37):
>> ...
>>> Silence means don't do it.
>>
>> Hmmm.... as a principle I'm more comfortable with "that which= isn't
>>prohibited is permitted"....
>>
>>> You would definitely NOT want BoRR to flush old stales.
>>
>> ....but, given the definite requirement, and given that the curren= t
>>precedent for "marking stale" does flush old stale, then = a few words
>>for the avoidance of doubt ?
>>
>>> Restarting the timer might be a good idea.
>>
>> I dunno... a route which remains stale for "a long time"= is, of
>>course, a candidate for being withdrawn: so having started a timer = the
>>first time things are set stale, I would avoid extending that -- at=
>>least for Graceful Restart, where the whole withdraw thing has been= "on-hold"
>>since the last session failed.  For route-refresh I guess ther= e's more
>>of a presumption that stale routes will be refreshed sooner or late= r,
>>and in the meantime they remain good.  So if the route-refresh= is
>>(repeatedly) restarted for some reason, perhaps it is more reasonab= le
>>to extend the flush deadline -- but avoid doing this indefinitely ?=
>>
>> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I ha= ve
>>built in Quagga prioritise route changes (pending changes and any t= hat
>>occur during the refresh) over refresh updates.  This makes it= more
>>likely that remaining stale routes are still good.  But the ot= her end
>>cannot know that.
>>
>> The paragraph in the draft discussing the "entire Adj-RIB-Out= "
>>defines that to be the entries present "at the start of the ro= ute
>>refresh operation", and observes that these comprise both reac= hable
>>and unreachable routes.  [An "of" after "compri= se" sets teeth on edge,
>>BTW.]  I'm really not sure what this paragraph is trying to te= ll me.
>> The reference to unreachable routes appears to suggest that pendin= g
>>withdraws should be sent as part of the refresh -- so not left to t= he
>>EoRR to implement at the end.  The point at which the EoRR is = sent is
>>defined such that it excludes any Adj-RIB-Out entries added after t= he
>>route-refresh started, but includes any which are changed during th= e
>>process.  It seems reasonable to delay any brand new reachable=
>>prefixes until after all previously announced ones have been refres= hed
>>and the EoRR sent -- if that's the intent here.  Changes which= occur
>>before the refresh gets to a given entry are pretty naturally swept= up
>>by the refresh.  Changes which occur after the refresh has gon= e past,
>>could/should be deferred to after the EoRR ?  Does it make a >>difference if the change is a withdraw ?  (Of course MRAI may = kick in here.  Ah.
>>MRAI and route-refresh, there's a topic !)
>>
>> I think the essence of the rule is that the EoRR should be sent on= ce
>>all prefixes previously advertised to the peer as reachable have be= en
>>refreshed, ie announced or withdrawn (at least) once.  Or, per= haps
>>more strictly, not *before* those prefixes have *all* been announce= d
>>once -- given that the EoRR will promptly bang un-advertised stuff = on the head.
>>Even more strictly perhaps: not send EoRR *before* any withdraws >>implied by it are required or desirable.
>>
>> Depending on the implementation, a given sender may or may not be<= br> >>able to determine the minimum set of updates required before sendin= g EoRR.
>>
>> If the refresh operation takes a long time, there may be good
>>routeing reasons to arrange for some route changes to be sent to th= e peer "early"
>>-- that is to send announcements which do not contribute to the
>>refresh, but which are important enough to warrant delaying the end= of
>>the refresh.  That could be a matter for recommendation(s) in = the standard.
>>
>> NB: given that the timing of the EoRR is tied to the state of the<= br> >>Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. &= nbsp;At
>>the beginning of the initial update, the Restarting and Receiving >>speakers have:
>>
>>  Restarting:  Empty Adj-RIB-In   Empty Adj-RIB-Out<= br> >>
>>  Receiving:   Empty Adj-RIB-Out  Stale Adj-RIB-In >>
>> Now suppose (bonkers or otherwise) the receiving speaker sends an = RRQ
>>part way through the initial update.  The restarting speaker r= esponds
>>with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specifica= tion.
>> The receiving speaker sees the EoRR, and flushes stale.
>>Unfortunately, if the restarting speaker has not yet fully populate= d
>>its Adj-RIB-Out, then many further routes will be sent before the E= oR
>>falls due -- but the receiving speaker has already flushed their ti= ny
>>posteriors :-(
>>
>> I am coming to the view that route-refresh during a Graceful Resta= rt
>>initial update is a horse of a different colour altogether.
>>
>> [So the assumption that EoRR and EoR are triggered by the same thi= ng
>>was completely wrong, and I apologise for it.]
>>
>> Chris
>>
>> _______________________________________________
>> 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
htt= ps://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,
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 authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr


--_000_3DD27E915FE24879B03E7C25FB66D4E5ericssoncom_-- From keyupate@cisco.com Wed Jan 29 09:30:40 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD611A021B for ; Wed, 29 Jan 2014 09:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQ4glSNnuP0q for ; Wed, 29 Jan 2014 09:30:36 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id F26D71A0216 for ; Wed, 29 Jan 2014 09:30:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34076; q=dns/txt; s=iport; t=1391016633; x=1392226233; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=tl+GGvna+qmZ9hlp/X1KrFoV5ugnLQjXAoPxu4FcP88=; b=LrPaqVm1TF1j2PISObZP5RS3Tl0iDJRV/qWZ3emHrmjRNxEMu1rWxSqx OOMaoow7L7yyDLLEe+S+8S8dzOw22HtXekqy396b2RpBDsNUXabgGmP7d 1yZSg4YFJo86VubikZuvMJjM2felDA3ltsjTpDVceGSIJtzIokCpT7/Oz Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFACs66VKtJV2b/2dsb2JhbABZgkhEOFa9AoEHFnSCJQEBAQQBAQEXVAsMBgEIEQMBAQEhAQYoBgsUCQgCBAENBYdxAxENqTeYMQ2IChMEjGqCBA0EBgEGhDIEljyBbIxehUGDLYIq X-IronPort-AV: E=Sophos;i="4.95,743,1384300800"; d="scan'208,217";a="16436781" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP; 29 Jan 2014 17:30:32 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0THUW7I006733 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Jan 2014 17:30:32 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.228]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Wed, 29 Jan 2014 11:30:31 -0600 From: "Keyur Patel (keyupate)" To: Robert Raszuk , "Dongjie (Jimmy)" Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPHRfOkeX0Ff7T2kONFJ6OHVSLvw== Date: Wed, 29 Jan 2014 17:30:30 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [128.107.163.31] Content-Type: multipart/alternative; boundary="_000_CF0E7B6B612A0keyupateciscocom_" MIME-Version: 1.0 Cc: "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 17:30:40 -0000 --_000_CF0E7B6B612A0keyupateciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The receiver should simply ignore (with logging an error) BORRs and EORRs b= efore the receipt of EOR. Regards, Keyur From: Robert Raszuk > Date: Wed, 29 Jan 2014 10:15:01 +0100 To: "Dongjie (Jimmy)" > Cc: Keyur Patel >, Jakob Heit= z >, "idr@ietf.or= g" > Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Jimmy and all, I think Enke and Keyur's proposed text with help from Jakob makes the behav= ior simplified and deterministic to hold on BoRR till first EoR is seen. IMHO it should be also spelled out what is the expected sequence error hand= ling here ... I think not following "MUST NOT" shall implicitly result in e= ntire session drop and complete restart ? Any error code ? Best, R. On Wed, Jan 29, 2014 at 9:22 AM, Dongjie (Jimmy) > wrote: Hi Robert, Agree that in these cases the RRQ cannot be ignored, so postpone may be a b= etter choice. While IMO stop the initial update and start over may delay the initial conv= ergence, and as you said it also relates to update group processing. What = do you think about the new text provided by Keyur? Best regards, Jie From: rraszuk@gmail.com [mailto:rraszuk@gmail.com= ] On Behalf Of Robert Raszuk Sent: Sunday, January 26, 2014 11:03 PM To: Dongjie (Jimmy) Cc: Keyur Patel (keyupate); Jakob Heitz; idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Jie, I think it actually very easy to say that initial update can not ever guara= ntee that RRQ received during its sending may meet the peer's need. Example 1: SAFI 128 - During receiving initial update from RR to PE new VRF got added = with new RT import. Unfortunately those updates received within initial upd= ate were already dropped as not interesting by the PE. RR must resend full = table after completed initial update. (Of course this is the case where the= re is no RTC and that's why RTC helps a lot here by incremental nature). Example 2: SAFI 1 - Operator has modified inbound policy on EBGP peer during processin= g of incoming updates and those originally were dropped. No soft reconfig i= n set. Conclusion: RRQ can not ever be ignored. Sure they can be delayed or batched (case of m= ultiple peers within the same update/peer group) sending near RRQs (cluster= of PEs got provisioned from central management station). But as Keyur alre= ady mentioned those are rather standard local implementation optimizations. Question: Does it maybe make sense to stop initial update when receiving RRQ from a p= eer and start over ? Of course if peer is part of large update group it wou= ld have to be removed dynamically from it so other members are not delayed.= In any case I think this does not impact the spec but the implementation. Cheers, R. On Sun, Jan 26, 2014 at 7:13 PM, Dongjie (Jimmy) > wrote: Hi Keyur, Jakob, Agree that "postpone" may be better. The point is we could avoid the compli= cated cases/considerations of performing route refresh during initial updat= e:) For "ignore", I was thinking of scenarios in which the route refresh requir= ement may already be met by the initial update, while I'd admit it is hard = to say... Best regards, Jie -----Original Message----- From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] Sent: Sunday, January 26, 2014 8:30 PM To: Jakob Heitz; Dongjie (Jimmy) Cc: idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Jie, I agree with Jakob. You could make it *an implementation behavior* to postp= one the route refresh reply. Regards, Keyur On 1/26/14 1:29 AM, "Jakob Heitz" > wrote: >You can definitely not ignore it, but you could postpone it. > >-- >Jakob Heitz. > >> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" > >>wrote: >> >> After reading the analyses in this thread, my personal feeling is >>maybe we should avoid the interleaving between GR initial update and >>route refresh/enhanced route refresh, since the initial update is just >>sending the whole Adj-RIB-Out, there is no obvious advantage to start >>a route refresh/enhance route refresh during it. So a speaker should >>ignore the RRQ received during the initial update. Thoughts? >> >> Best regards, >> Jie >> >> -----Original Message----- >> From: Idr [mailto:idr-bounces@ietf.org] On = Behalf Of Jakob Heitz >> Sent: Saturday, January 25, 2014 10:48 PM >> To: Chris Hall; idr@ietf.org >> Subject: Re: [Idr] WG LC for >> draft-ietf-idr-bgp-enhanced-route-refresh >> >> RFCs are written for coders "practiced" in the art". >> If anyone sends an EoRR before the adj-RIB-out is fully populated, >>then it's a BUG. >> This does not need to be said. >> >> Personally, I believe a route refresh request should not be honored >>until GR is complete. >> Also, I don't believe a timer for the receipt of EoRR is necessary, >>because the EoRR is guaranteed. >> Guaranteed means "unless the session drops first". >> -- >> >> Jakob Heitz. >> >> ________________________________________ >> From: Chris Hall [chris.hall@highwayman.com] >> Sent: Saturday, 25 January 2014 11:27 AM >> To: idr@ietf.org >> Cc: Jakob Heitz >> Subject: RE: [Idr] WG LC for >> draft-ietf-idr-bgp-enhanced-route-refresh >> >> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): >> ... >>> Silence means don't do it. >> >> Hmmm.... as a principle I'm more comfortable with "that which isn't >>prohibited is permitted".... >> >>> You would definitely NOT want BoRR to flush old stales. >> >> ....but, given the definite requirement, and given that the current >>precedent for "marking stale" does flush old stale, then a few words >>for the avoidance of doubt ? >> >>> Restarting the timer might be a good idea. >> >> I dunno... a route which remains stale for "a long time" is, of >>course, a candidate for being withdrawn: so having started a timer the >>first time things are set stale, I would avoid extending that -- at >>least for Graceful Restart, where the whole withdraw thing has been "on-h= old" >>since the last session failed. For route-refresh I guess there's more >>of a presumption that stale routes will be refreshed sooner or later, >>and in the meantime they remain good. So if the route-refresh is >>(repeatedly) restarted for some reason, perhaps it is more reasonable >>to extend the flush deadline -- but avoid doing this indefinitely ? >> >> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I have >>built in Quagga prioritise route changes (pending changes and any that >>occur during the refresh) over refresh updates. This makes it more >>likely that remaining stale routes are still good. But the other end >>cannot know that. >> >> The paragraph in the draft discussing the "entire Adj-RIB-Out" >>defines that to be the entries present "at the start of the route >>refresh operation", and observes that these comprise both reachable >>and unreachable routes. [An "of" after "comprise" sets teeth on edge, >>BTW.] I'm really not sure what this paragraph is trying to tell me. >> The reference to unreachable routes appears to suggest that pending >>withdraws should be sent as part of the refresh -- so not left to the >>EoRR to implement at the end. The point at which the EoRR is sent is >>defined such that it excludes any Adj-RIB-Out entries added after the >>route-refresh started, but includes any which are changed during the >>process. It seems reasonable to delay any brand new reachable >>prefixes until after all previously announced ones have been refreshed >>and the EoRR sent -- if that's the intent here. Changes which occur >>before the refresh gets to a given entry are pretty naturally swept up >>by the refresh. Changes which occur after the refresh has gone past, >>could/should be deferred to after the EoRR ? Does it make a >>difference if the change is a withdraw ? (Of course MRAI may kick in her= e. Ah. >>MRAI and route-refresh, there's a topic !) >> >> I think the essence of the rule is that the EoRR should be sent once >>all prefixes previously advertised to the peer as reachable have been >>refreshed, ie announced or withdrawn (at least) once. Or, perhaps >>more strictly, not *before* those prefixes have *all* been announced >>once -- given that the EoRR will promptly bang un-advertised stuff on the= head. >>Even more strictly perhaps: not send EoRR *before* any withdraws >>implied by it are required or desirable. >> >> Depending on the implementation, a given sender may or may not be >>able to determine the minimum set of updates required before sending EoRR= . >> >> If the refresh operation takes a long time, there may be good >>routeing reasons to arrange for some route changes to be sent to the peer= "early" >>-- that is to send announcements which do not contribute to the >>refresh, but which are important enough to warrant delaying the end of >>the refresh. That could be a matter for recommendation(s) in the standar= d. >> >> NB: given that the timing of the EoRR is tied to the state of the >>Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. At >>the beginning of the initial update, the Restarting and Receiving >>speakers have: >> >> Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out >> >> Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In >> >> Now suppose (bonkers or otherwise) the receiving speaker sends an RRQ >>part way through the initial update. The restarting speaker responds >>with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specification. >> The receiving speaker sees the EoRR, and flushes stale. >>Unfortunately, if the restarting speaker has not yet fully populated >>its Adj-RIB-Out, then many further routes will be sent before the EoR >>falls due -- but the receiving speaker has already flushed their tiny >>posteriors :-( >> >> I am coming to the view that route-refresh during a Graceful Restart >>initial update is a horse of a different colour altogether. >> >> [So the assumption that EoRR and EoR are triggered by the same thing >>was completely wrong, and I apologise for it.] >> >> Chris >> >> _______________________________________________ >> 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_CF0E7B6B612A0keyupateciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
The receiver should simply ignore (with logging an error) BORRs and EO= RRs before the receipt of EOR.  

Regards,
Keyur

From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 29 Jan 2014 10:15:01 = 3;0100
To: "Dongjie (Jimmy)" <= ;jie.dong@huawei.com>
Cc: Keyur Patel <keyupate@cisco.com>, Jakob Heitz <jakob.heitz@ericsson.com>, &quo= t;idr@ietf.org" <idr@ietf.org>
Subject: Re: [Idr] WG LC for draft-= ietf-idr-bgp-enhanced-route-refresh

Hi Jimmy and all,

I think Enke and Keyur's proposed text with help from Jakob makes the behav= ior simplified and deterministic to hold on BoRR till first EoR is seen.

IMHO it should be also spelled out what is the expected sequence error hand= ling here ... I think not following "MUST NOT" shall implicitly r= esult in entire session drop and complete restart ? Any error code ?

Best,
R.



On Wed, Jan 29, 2014 at 9:22 AM, Dongjie (Jimmy)= <jie.dong@huawe= i.com> wrote:

Hi Robert,

 <= /u>

Agree that in the= se cases the RRQ cannot be ignored, so postpone may be a better choice.<= /u>

 <= /u>

While IMO stop th= e initial update and start over may delay the initial convergence, and as y= ou said  it also relates to update group processing. What do you think about the new text provided by Keyur?

 <= /u>

Best regards,=

Jie

 <= /u>

From: rraszuk@gmail.com [mailto:rraszuk@gm= ail.com] On Behalf Of Robert Raszuk
Sent: Sunday, January 26, 2014 11:03 PM
To: Dongjie (Jimmy)
Cc: Keyur Patel (keyupate); Jakob Heitz; idr@ietf.org


Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refre= sh

 

Hi Jie,

 

I think it actually very easy to say that initial update can not ev= er guarantee that RRQ received during its sending may meet the peer's need.=

 

Example 1:

 

SAFI 128 - During receiving initial update from RR to PE new VRF go= t added with new RT import. Unfortunately those updates received within ini= tial update were already dropped as not interesting by the PE. RR must resend full table after completed initial u= pdate. (Of course this is the case where there is no RTC and that's why RTC= helps a lot here by incremental nature). 

 

Example 2: 

 

SAFI 1 - Operator has modified inbound policy on EBGP peer during p= rocessing of incoming updates and those originally were dropped. No soft re= config in set. 

 

Conclusion:

 

RRQ can not ever be ignored. Sure they can be delayed or batched (c= ase of multiple peers within the same update/peer group) sending near RRQs = (cluster of PEs got provisioned from central management station). But as Keyur already mentioned those are rather stand= ard local implementation optimizations. 

 

Question:

 

Does it maybe make sense to stop initial update when receiving RRQ = from a peer and start over ? Of course if peer is part of large update grou= p it would have to be removed dynamically from it so other members are not delayed. In any case I think this does no= t impact the spec but the implementation.

 

Cheers,
R.

 

 

 

On Sun, Jan 26, 2014 at 7:13 PM= , Dongjie (Jimmy) <jie.dong@huawei.com> wrote:

Hi Keyur, Jakob,

Agree that "postpone" may be better. The point is we could avoid = the complicated cases/considerations of performing route refresh during ini= tial update:)

For "ignore", I was thinking of scenarios in which the route refr= esh requirement may already be met by the initial update, while I'd admit i= t is hard to say...



Best regards,
Jie

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

From: Keyur Patel (keyupate) [m= ailto:keyupate@cisc= o.com]
Sent: Sunday, January 26, 2014 8:30 PM
To: Jakob Heitz; Dongjie (Jimmy)
Cc: idr@ietf.org
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Jie,

I agree with Jakob. You could make it *an implementation behavior* to postp= one the route refresh reply.


Regards,
Keyur

On 1/26/14 1:29 AM, "Jakob Heitz" <jakob.heitz@ericsson.com> wrote:<= br>
>You can definitely not ignore it, but you could postpone it.
>
>--
>Jakob Heitz.
>
>> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" <jie.dong@huawei.com>
>>wrote:
>>
>> After reading the analyses in this thread, my personal feeling is<= br> >>maybe we should avoid the interleaving between GR initial update an= d
>>route refresh/enhanced route refresh, since the initial update is j= ust
>>sending the whole Adj-RIB-Out, there is no obvious advantage to sta= rt
>>a route refresh/enhance route refresh during it. So a speaker shoul= d
>>ignore the RRQ received during the initial update. Thoughts?
>>
>> Best regards,
>> Jie
>>
>> -----Original Message-----
>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz
>> Sent: Saturday, January 25, 2014 10:48 PM
>> To: Chris Hall; = idr@ietf.org
>> Subject: Re: [Idr] WG LC for
>> draft-ietf-idr-bgp-enhanced-route-refresh
>>
>> RFCs are written for coders "practiced" in the art"= .
>> If anyone sends an EoRR before the adj-RIB-out is fully populated,=
>>then it's a BUG.
>> This does not need to be said.
>>
>> Personally, I believe a route refresh request should not be honore= d
>>until GR is complete.
>> Also, I don't believe a timer for the receipt of EoRR is necessary= ,
>>because the EoRR is guaranteed.
>> Guaranteed means "unless the session drops first".
>> --
>>
>> Jakob Heitz.
>>
>> ________________________________________
>> From: Chris Hall [chris.hall@highwayman.com]
>> Sent: Saturday, 25 January 2014 11:27 AM
>> To: idr@ietf.org=
>> Cc: Jakob Heitz
>> Subject: RE: [Idr] WG LC for
>> draft-ietf-idr-bgp-enhanced-route-refresh
>>
>> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37):
>> ...
>>> Silence means don't do it.
>>
>> Hmmm.... as a principle I'm more comfortable with "that which= isn't
>>prohibited is permitted"....
>>
>>> You would definitely NOT want BoRR to flush old stales.
>>
>> ....but, given the definite requirement, and given that the curren= t
>>precedent for "marking stale" does flush old stale, then = a few words
>>for the avoidance of doubt ?
>>
>>> Restarting the timer might be a good idea.
>>
>> I dunno... a route which remains stale for "a long time"= is, of
>>course, a candidate for being withdrawn: so having started a timer = the
>>first time things are set stale, I would avoid extending that -- at=
>>least for Graceful Restart, where the whole withdraw thing has been= "on-hold"
>>since the last session failed.  For route-refresh I guess ther= e's more
>>of a presumption that stale routes will be refreshed sooner or late= r,
>>and in the meantime they remain good.  So if the route-refresh= is
>>(repeatedly) restarted for some reason, perhaps it is more reasonab= le
>>to extend the flush deadline -- but avoid doing this indefinitely ?=
>>
>> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I ha= ve
>>built in Quagga prioritise route changes (pending changes and any t= hat
>>occur during the refresh) over refresh updates.  This makes it= more
>>likely that remaining stale routes are still good.  But the ot= her end
>>cannot know that.
>>
>> The paragraph in the draft discussing the "entire Adj-RIB-Out= "
>>defines that to be the entries present "at the start of the ro= ute
>>refresh operation", and observes that these comprise both reac= hable
>>and unreachable routes.  [An "of" after "compri= se" sets teeth on edge,
>>BTW.]  I'm really not sure what this paragraph is trying to te= ll me.
>> The reference to unreachable routes appears to suggest that pendin= g
>>withdraws should be sent as part of the refresh -- so not left to t= he
>>EoRR to implement at the end.  The point at which the EoRR is = sent is
>>defined such that it excludes any Adj-RIB-Out entries added after t= he
>>route-refresh started, but includes any which are changed during th= e
>>process.  It seems reasonable to delay any brand new reachable=
>>prefixes until after all previously announced ones have been refres= hed
>>and the EoRR sent -- if that's the intent here.  Changes which= occur
>>before the refresh gets to a given entry are pretty naturally swept= up
>>by the refresh.  Changes which occur after the refresh has gon= e past,
>>could/should be deferred to after the EoRR ?  Does it make a >>difference if the change is a withdraw ?  (Of course MRAI may = kick in here.  Ah.
>>MRAI and route-refresh, there's a topic !)
>>
>> I think the essence of the rule is that the EoRR should be sent on= ce
>>all prefixes previously advertised to the peer as reachable have be= en
>>refreshed, ie announced or withdrawn (at least) once.  Or, per= haps
>>more strictly, not *before* those prefixes have *all* been announce= d
>>once -- given that the EoRR will promptly bang un-advertised stuff = on the head.
>>Even more strictly perhaps: not send EoRR *before* any withdraws >>implied by it are required or desirable.
>>
>> Depending on the implementation, a given sender may or may not be<= br> >>able to determine the minimum set of updates required before sendin= g EoRR.
>>
>> If the refresh operation takes a long time, there may be good
>>routeing reasons to arrange for some route changes to be sent to th= e peer "early"
>>-- that is to send announcements which do not contribute to the
>>refresh, but which are important enough to warrant delaying the end= of
>>the refresh.  That could be a matter for recommendation(s) in = the standard.
>>
>> NB: given that the timing of the EoRR is tied to the state of the<= br> >>Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. &= nbsp;At
>>the beginning of the initial update, the Restarting and Receiving >>speakers have:
>>
>>  Restarting:  Empty Adj-RIB-In   Empty Adj-RIB-Out<= br> >>
>>  Receiving:   Empty Adj-RIB-Out  Stale Adj-RIB-In >>
>> Now suppose (bonkers or otherwise) the receiving speaker sends an = RRQ
>>part way through the initial update.  The restarting speaker r= esponds
>>with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specifica= tion.
>> The receiving speaker sees the EoRR, and flushes stale.
>>Unfortunately, if the restarting speaker has not yet fully populate= d
>>its Adj-RIB-Out, then many further routes will be sent before the E= oR
>>falls due -- but the receiving speaker has already flushed their ti= ny
>>posteriors :-(
>>
>> I am coming to the view that route-refresh during a Graceful Resta= rt
>>initial update is a horse of a different colour altogether.
>>
>> [So the assumption that EoRR and EoR are triggered by the same thi= ng
>>was completely wrong, and I apologise for it.]
>>
>> Chris
>>
>> _______________________________________________
>> 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
htt= ps://www.ietf.org/mailman/listinfo/idr

 


--_000_CF0E7B6B612A0keyupateciscocom_-- From thomas.mangin@exa-networks.co.uk Wed Jan 29 11:58:37 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8591A03E1; Wed, 29 Jan 2014 11:58:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvapcQNvEsuK; Wed, 29 Jan 2014 11:58:32 -0800 (PST) Received: from out-7.mail.exa.net.uk (out-7.mail.exa.net.uk [82.219.4.135]) by ietfa.amsl.com (Postfix) with ESMTP id 946921A029B; Wed, 29 Jan 2014 11:58:31 -0800 (PST) Received: from smtp-3.mail.exa.net.uk (smtp-1.mail.exa.net.uk [82.219.5.1]) by out-7.mail.exa.net.uk (ExaSMTPD) with ESMTP id 868B1A0053; Wed, 29 Jan 2014 19:58:27 +0000 (GMT) Received: from [192.168.1.16] (ptr-1.212.219.82.rev.exa.net.uk [82.219.212.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: thomas@mangin.com) by smtp-3.mail.exa.net.uk (ExaSMTPD) with ESMTPSA id 91B8522115D; Wed, 29 Jan 2014 19:58:26 +0000 (GMT) Content-Type: multipart/signed; boundary="Apple-Mail=_7E6A468F-8ABF-4E76-880C-863CA507CA2A"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Mangin In-Reply-To: Date: Wed, 29 Jan 2014 19:58:25 +0000 Message-Id: References: To: idr-bounces@ietf.org X-Mailer: Apple Mail (2.1827) X-Virus-Scanned: clamav-milter 0.97.8 at out-2-2.mail.exa.net.uk X-Virus-Status: Clean Cc: Robert Raszuk , "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 19:58:37 -0000 --Apple-Mail=_7E6A468F-8ABF-4E76-880C-863CA507CA2A Content-Type: multipart/alternative; boundary="Apple-Mail=_61D008FB-B124-4468-A55B-B3069A8D235E" --Apple-Mail=_61D008FB-B124-4468-A55B-B3069A8D235E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This would be the simplest solution. And ignore EoRR which have no BeRR associated (for the case BoRR EoR = EoRR). Thomas On 29 Jan 2014, at 17:30, Keyur Patel (keyupate) = wrote: > The receiver should simply ignore (with logging an error) BORRs and = EORRs before the receipt of EOR. =20 >=20 > Regards, > Keyur >=20 > From: Robert Raszuk > Date: Wed, 29 Jan 2014 10:15:01 +0100 > To: "Dongjie (Jimmy)" > Cc: Keyur Patel , Jakob Heitz = , "idr@ietf.org" > Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh >=20 > Hi Jimmy and all, >=20 > I think Enke and Keyur's proposed text with help from Jakob makes the = behavior simplified and deterministic to hold on BoRR till first EoR is = seen. >=20 > IMHO it should be also spelled out what is the expected sequence error = handling here ... I think not following "MUST NOT" shall implicitly = result in entire session drop and complete restart ? Any error code ? >=20 > Best, > R. >=20 >=20 >=20 > On Wed, Jan 29, 2014 at 9:22 AM, Dongjie (Jimmy) = wrote: >> Hi Robert, >> =20 >> Agree that in these cases the RRQ cannot be ignored, so postpone may = be a better choice. >> =20 >> While IMO stop the initial update and start over may delay the = initial convergence, and as you said it also relates to update group = processing. What do you think about the new text provided by Keyur? >> =20 >> Best regards, >>=20 >> Jie >>=20 >> =20 >> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of = Robert Raszuk >> Sent: Sunday, January 26, 2014 11:03 PM >> To: Dongjie (Jimmy) >> Cc: Keyur Patel (keyupate); Jakob Heitz; idr@ietf.org >>=20 >> Subject: Re: [Idr] WG LC for = draft-ietf-idr-bgp-enhanced-route-refresh >>=20 >> =20 >> Hi Jie, >> =20 >> I think it actually very easy to say that initial update can not ever = guarantee that RRQ received during its sending may meet the peer's need. >> =20 >> Example 1: >> =20 >> SAFI 128 - During receiving initial update from RR to PE new VRF got = added with new RT import. Unfortunately those updates received within = initial update were already dropped as not interesting by the PE. RR = must resend full table after completed initial update. (Of course this = is the case where there is no RTC and that's why RTC helps a lot here by = incremental nature).=20 >> =20 >> Example 2:=20 >> =20 >> SAFI 1 - Operator has modified inbound policy on EBGP peer during = processing of incoming updates and those originally were dropped. No = soft reconfig in set.=20 >> =20 >> Conclusion: >> =20 >> RRQ can not ever be ignored. Sure they can be delayed or batched = (case of multiple peers within the same update/peer group) sending near = RRQs (cluster of PEs got provisioned from central management station). = But as Keyur already mentioned those are rather standard local = implementation optimizations.=20 >> =20 >> Question: >> =20 >> Does it maybe make sense to stop initial update when receiving RRQ = from a peer and start over ? Of course if peer is part of large update = group it would have to be removed dynamically from it so other members = are not delayed. In any case I think this does not impact the spec but = the implementation. >> =20 >> Cheers, >> R. >> =20 >> =20 >> =20 >> On Sun, Jan 26, 2014 at 7:13 PM, Dongjie (Jimmy) = wrote: >> Hi Keyur, Jakob, >>=20 >> Agree that "postpone" may be better. The point is we could avoid the = complicated cases/considerations of performing route refresh during = initial update:) >>=20 >> For "ignore", I was thinking of scenarios in which the route refresh = requirement may already be met by the initial update, while I'd admit it = is hard to say... >>=20 >>=20 >> Best regards, >> Jie >>=20 >> -----Original Message----- >> From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] >> Sent: Sunday, January 26, 2014 8:30 PM >> To: Jakob Heitz; Dongjie (Jimmy) >> Cc: idr@ietf.org >> Subject: Re: [Idr] WG LC for = draft-ietf-idr-bgp-enhanced-route-refresh >>=20 >> Jie, >>=20 >> I agree with Jakob. You could make it *an implementation behavior* to = postpone the route refresh reply. >>=20 >>=20 >> Regards, >> Keyur >>=20 >> On 1/26/14 1:29 AM, "Jakob Heitz" wrote: >>=20 >> >You can definitely not ignore it, but you could postpone it. >> > >> >-- >> >Jakob Heitz. >> > >> >> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" = >> >>wrote: >> >> >> >> After reading the analyses in this thread, my personal feeling is >> >>maybe we should avoid the interleaving between GR initial update = and >> >>route refresh/enhanced route refresh, since the initial update is = just >> >>sending the whole Adj-RIB-Out, there is no obvious advantage to = start >> >>a route refresh/enhance route refresh during it. So a speaker = should >> >>ignore the RRQ received during the initial update. Thoughts? >> >> >> >> Best regards, >> >> Jie >> >> >> >> -----Original Message----- >> >> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz >> >> Sent: Saturday, January 25, 2014 10:48 PM >> >> To: Chris Hall; idr@ietf.org >> >> Subject: Re: [Idr] WG LC for >> >> draft-ietf-idr-bgp-enhanced-route-refresh >> >> >> >> RFCs are written for coders "practiced" in the art". >> >> If anyone sends an EoRR before the adj-RIB-out is fully populated, >> >>then it's a BUG. >> >> This does not need to be said. >> >> >> >> Personally, I believe a route refresh request should not be = honored >> >>until GR is complete. >> >> Also, I don't believe a timer for the receipt of EoRR is = necessary, >> >>because the EoRR is guaranteed. >> >> Guaranteed means "unless the session drops first". >> >> -- >> >> >> >> Jakob Heitz. >> >> >> >> ________________________________________ >> >> From: Chris Hall [chris.hall@highwayman.com] >> >> Sent: Saturday, 25 January 2014 11:27 AM >> >> To: idr@ietf.org >> >> Cc: Jakob Heitz >> >> Subject: RE: [Idr] WG LC for >> >> draft-ietf-idr-bgp-enhanced-route-refresh >> >> >> >> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): >> >> ... >> >>> Silence means don't do it. >> >> >> >> Hmmm.... as a principle I'm more comfortable with "that which = isn't >> >>prohibited is permitted".... >> >> >> >>> You would definitely NOT want BoRR to flush old stales. >> >> >> >> ....but, given the definite requirement, and given that the = current >> >>precedent for "marking stale" does flush old stale, then a few = words >> >>for the avoidance of doubt ? >> >> >> >>> Restarting the timer might be a good idea. >> >> >> >> I dunno... a route which remains stale for "a long time" is, of >> >>course, a candidate for being withdrawn: so having started a timer = the >> >>first time things are set stale, I would avoid extending that -- at >> >>least for Graceful Restart, where the whole withdraw thing has been = "on-hold" >> >>since the last session failed. For route-refresh I guess there's = more >> >>of a presumption that stale routes will be refreshed sooner or = later, >> >>and in the meantime they remain good. So if the route-refresh is >> >>(repeatedly) restarted for some reason, perhaps it is more = reasonable >> >>to extend the flush deadline -- but avoid doing this indefinitely ? >> >> >> >> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I = have >> >>built in Quagga prioritise route changes (pending changes and any = that >> >>occur during the refresh) over refresh updates. This makes it more >> >>likely that remaining stale routes are still good. But the other = end >> >>cannot know that. >> >> >> >> The paragraph in the draft discussing the "entire Adj-RIB-Out" >> >>defines that to be the entries present "at the start of the route >> >>refresh operation", and observes that these comprise both reachable >> >>and unreachable routes. [An "of" after "comprise" sets teeth on = edge, >> >>BTW.] I'm really not sure what this paragraph is trying to tell = me. >> >> The reference to unreachable routes appears to suggest that = pending >> >>withdraws should be sent as part of the refresh -- so not left to = the >> >>EoRR to implement at the end. The point at which the EoRR is sent = is >> >>defined such that it excludes any Adj-RIB-Out entries added after = the >> >>route-refresh started, but includes any which are changed during = the >> >>process. It seems reasonable to delay any brand new reachable >> >>prefixes until after all previously announced ones have been = refreshed >> >>and the EoRR sent -- if that's the intent here. Changes which = occur >> >>before the refresh gets to a given entry are pretty naturally swept = up >> >>by the refresh. Changes which occur after the refresh has gone = past, >> >>could/should be deferred to after the EoRR ? Does it make a >> >>difference if the change is a withdraw ? (Of course MRAI may kick = in here. Ah. >> >>MRAI and route-refresh, there's a topic !) >> >> >> >> I think the essence of the rule is that the EoRR should be sent = once >> >>all prefixes previously advertised to the peer as reachable have = been >> >>refreshed, ie announced or withdrawn (at least) once. Or, perhaps >> >>more strictly, not *before* those prefixes have *all* been = announced >> >>once -- given that the EoRR will promptly bang un-advertised stuff = on the head. >> >>Even more strictly perhaps: not send EoRR *before* any withdraws >> >>implied by it are required or desirable. >> >> >> >> Depending on the implementation, a given sender may or may not be >> >>able to determine the minimum set of updates required before = sending EoRR. >> >> >> >> If the refresh operation takes a long time, there may be good >> >>routeing reasons to arrange for some route changes to be sent to = the peer "early" >> >>-- that is to send announcements which do not contribute to the >> >>refresh, but which are important enough to warrant delaying the end = of >> >>the refresh. That could be a matter for recommendation(s) in the = standard. >> >> >> >> NB: given that the timing of the EoRR is tied to the state of the >> >>Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. = At >> >>the beginning of the initial update, the Restarting and Receiving >> >>speakers have: >> >> >> >> Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out >> >> >> >> Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In >> >> >> >> Now suppose (bonkers or otherwise) the receiving speaker sends an = RRQ >> >>part way through the initial update. The restarting speaker = responds >> >>with BoRR, everything in its Adj-RIB-Out, and EoRR -- per = specification. >> >> The receiving speaker sees the EoRR, and flushes stale. >> >>Unfortunately, if the restarting speaker has not yet fully = populated >> >>its Adj-RIB-Out, then many further routes will be sent before the = EoR >> >>falls due -- but the receiving speaker has already flushed their = tiny >> >>posteriors :-( >> >> >> >> I am coming to the view that route-refresh during a Graceful = Restart >> >>initial update is a horse of a different colour altogether. >> >> >> >> [So the assumption that EoRR and EoR are triggered by the same = thing >> >>was completely wrong, and I apologise for it.] >> >> >> >> Chris >> >> >> >> _______________________________________________ >> >> 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 >>=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 --Apple-Mail=_61D008FB-B124-4468-A55B-B3069A8D235E Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii This would be the simplest solution.
And ignore EoRR which have no BeRR associated (for the case BoRR EoR EoRR).

Thomas

On 29 Jan 2014, at 17:30, Keyur Patel (keyupate) <keyupate@cisco.com> wrote:

The receiver should simply ignore (with logging an error) BORRs and EORRs before the receipt of EOR.  

Regards,
Keyur

From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 29 Jan 2014 10:15:01 +0100
To: "Dongjie (Jimmy)" <jie.dong@huawei.com>
Cc: Keyur Patel <keyupate@cisco.com>, Jakob Heitz <jakob.heitz@ericsson.com>, "idr@ietf.org" <idr@ietf.org>
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Hi Jimmy and all,

I think Enke and Keyur's proposed text with help from Jakob makes the behavior simplified and deterministic to hold on BoRR till first EoR is seen.

IMHO it should be also spelled out what is the expected sequence error handling here ... I think not following "MUST NOT" shall implicitly result in entire session drop and complete restart ? Any error code ?

Best,
R.



On Wed, Jan 29, 2014 at 9:22 AM, Dongjie (Jimmy) <jie.dong@huawei.com> wrote:
Hi Robert,
 
Agree that in these cases the RRQ cannot be ignored, so postpone may be a better choice.
 
While IMO stop the initial update and start over may delay the initial convergence, and as you said  it also relates to update group processing. What do you think about the new text provided by Keyur?
 

Best regards,

Jie

 
From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Raszuk
Sent: Sunday, January 26, 2014 11:03 PM
To: Dongjie (Jimmy)
Cc: Keyur Patel (keyupate); Jakob Heitz; idr@ietf.org

Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

 
Hi Jie,
 
I think it actually very easy to say that initial update can not ever guarantee that RRQ received during its sending may meet the peer's need.
 
Example 1:
 
SAFI 128 - During receiving initial update from RR to PE new VRF got added with new RT import. Unfortunately those updates received within initial update were already dropped as not interesting by the PE. RR must resend full table after completed initial update. (Of course this is the case where there is no RTC and that's why RTC helps a lot here by incremental nature). 
 
Example 2: 
 
SAFI 1 - Operator has modified inbound policy on EBGP peer during processing of incoming updates and those originally were dropped. No soft reconfig in set. 
 
Conclusion:
 
RRQ can not ever be ignored. Sure they can be delayed or batched (case of multiple peers within the same update/peer group) sending near RRQs (cluster of PEs got provisioned from central management station). But as Keyur already mentioned those are rather standard local implementation optimizations. 
 
Question:
 
Does it maybe make sense to stop initial update when receiving RRQ from a peer and start over ? Of course if peer is part of large update group it would have to be removed dynamically from it so other members are not delayed. In any case I think this does not impact the spec but the implementation.
 
Cheers,
R.
 
 
 
On Sun, Jan 26, 2014 at 7:13 PM, Dongjie (Jimmy) <jie.dong@huawei.com> wrote:
Hi Keyur, Jakob,

Agree that "postpone" may be better. The point is we could avoid the complicated cases/considerations of performing route refresh during initial update:)

For "ignore", I was thinking of scenarios in which the route refresh requirement may already be met by the initial update, while I'd admit it is hard to say...


Best regards,
Jie

-----Original Message-----
From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com]
Sent: Sunday, January 26, 2014 8:30 PM
To: Jakob Heitz; Dongjie (Jimmy)
Cc: idr@ietf.org
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Jie,

I agree with Jakob. You could make it *an implementation behavior* to postpone the route refresh reply.


Regards,
Keyur

On 1/26/14 1:29 AM, "Jakob Heitz" <jakob.heitz@ericsson.com> wrote:

>You can definitely not ignore it, but you could postpone it.
>
>--
>Jakob Heitz.
>
>> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" <jie.dong@huawei.com>
>>wrote:
>>
>> After reading the analyses in this thread, my personal feeling is
>>maybe we should avoid the interleaving between GR initial update and
>>route refresh/enhanced route refresh, since the initial update is just
>>sending the whole Adj-RIB-Out, there is no obvious advantage to start
>>a route refresh/enhance route refresh during it. So a speaker should
>>ignore the RRQ received during the initial update. Thoughts?
>>
>> Best regards,
>> Jie
>>
>> -----Original Message-----
>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz
>> Sent: Saturday, January 25, 2014 10:48 PM
>> To: Chris Hall; idr@ietf.org
>> Subject: Re: [Idr] WG LC for
>> draft-ietf-idr-bgp-enhanced-route-refresh
>>
>> RFCs are written for coders "practiced" in the art".
>> If anyone sends an EoRR before the adj-RIB-out is fully populated,
>>then it's a BUG.
>> This does not need to be said.
>>
>> Personally, I believe a route refresh request should not be honored
>>until GR is complete.
>> Also, I don't believe a timer for the receipt of EoRR is necessary,
>>because the EoRR is guaranteed.
>> Guaranteed means "unless the session drops first".
>> --
>>
>> Jakob Heitz.
>>
>> ________________________________________
>> From: Chris Hall [chris.hall@highwayman.com]
>> Sent: Saturday, 25 January 2014 11:27 AM
>> To: idr@ietf.org
>> Cc: Jakob Heitz
>> Subject: RE: [Idr] WG LC for
>> draft-ietf-idr-bgp-enhanced-route-refresh
>>
>> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37):
>> ...
>>> Silence means don't do it.
>>
>> Hmmm.... as a principle I'm more comfortable with "that which isn't
>>prohibited is permitted"....
>>
>>> You would definitely NOT want BoRR to flush old stales.
>>
>> ....but, given the definite requirement, and given that the current
>>precedent for "marking stale" does flush old stale, then a few words
>>for the avoidance of doubt ?
>>
>>> Restarting the timer might be a good idea.
>>
>> I dunno... a route which remains stale for "a long time" is, of
>>course, a candidate for being withdrawn: so having started a timer the
>>first time things are set stale, I would avoid extending that -- at
>>least for Graceful Restart, where the whole withdraw thing has been "on-hold"
>>since the last session failed.  For route-refresh I guess there's more
>>of a presumption that stale routes will be refreshed sooner or later,
>>and in the meantime they remain good.  So if the route-refresh is
>>(repeatedly) restarted for some reason, perhaps it is more reasonable
>>to extend the flush deadline -- but avoid doing this indefinitely ?
>>
>> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I have
>>built in Quagga prioritise route changes (pending changes and any that
>>occur during the refresh) over refresh updates.  This makes it more
>>likely that remaining stale routes are still good.  But the other end
>>cannot know that.
>>
>> The paragraph in the draft discussing the "entire Adj-RIB-Out"
>>defines that to be the entries present "at the start of the route
>>refresh operation", and observes that these comprise both reachable
>>and unreachable routes.  [An "of" after "comprise" sets teeth on edge,
>>BTW.]  I'm really not sure what this paragraph is trying to tell me.
>> The reference to unreachable routes appears to suggest that pending
>>withdraws should be sent as part of the refresh -- so not left to the
>>EoRR to implement at the end.  The point at which the EoRR is sent is
>>defined such that it excludes any Adj-RIB-Out entries added after the
>>route-refresh started, but includes any which are changed during the
>>process.  It seems reasonable to delay any brand new reachable
>>prefixes until after all previously announced ones have been refreshed
>>and the EoRR sent -- if that's the intent here.  Changes which occur
>>before the refresh gets to a given entry are pretty naturally swept up
>>by the refresh.  Changes which occur after the refresh has gone past,
>>could/should be deferred to after the EoRR ?  Does it make a
>>difference if the change is a withdraw ?  (Of course MRAI may kick in here.  Ah.
>>MRAI and route-refresh, there's a topic !)
>>
>> I think the essence of the rule is that the EoRR should be sent once
>>all prefixes previously advertised to the peer as reachable have been
>>refreshed, ie announced or withdrawn (at least) once.  Or, perhaps
>>more strictly, not *before* those prefixes have *all* been announced
>>once -- given that the EoRR will promptly bang un-advertised stuff on the head.
>>Even more strictly perhaps: not send EoRR *before* any withdraws
>>implied by it are required or desirable.
>>
>> Depending on the implementation, a given sender may or may not be
>>able to determine the minimum set of updates required before sending EoRR.
>>
>> If the refresh operation takes a long time, there may be good
>>routeing reasons to arrange for some route changes to be sent to the peer "early"
>>-- that is to send announcements which do not contribute to the
>>refresh, but which are important enough to warrant delaying the end of
>>the refresh.  That could be a matter for recommendation(s) in the standard.
>>
>> NB: given that the timing of the EoRR is tied to the state of the
>>Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions.  At
>>the beginning of the initial update, the Restarting and Receiving
>>speakers have:
>>
>>  Restarting:  Empty Adj-RIB-In   Empty Adj-RIB-Out
>>
>>  Receiving:   Empty Adj-RIB-Out  Stale Adj-RIB-In
>>
>> Now suppose (bonkers or otherwise) the receiving speaker sends an RRQ
>>part way through the initial update.  The restarting speaker responds
>>with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specification.
>> The receiving speaker sees the EoRR, and flushes stale.
>>Unfortunately, if the restarting speaker has not yet fully populated
>>its Adj-RIB-Out, then many further routes will be sent before the EoR
>>falls due -- but the receiving speaker has already flushed their tiny
>>posteriors :-(
>>
>> I am coming to the view that route-refresh during a Graceful Restart
>>initial update is a horse of a different colour altogether.
>>
>> [So the assumption that EoRR and EoR are triggered by the same thing
>>was completely wrong, and I apologise for it.]
>>
>> Chris
>>
>> _______________________________________________
>> 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

--Apple-Mail=_61D008FB-B124-4468-A55B-B3069A8D235E-- --Apple-Mail=_7E6A468F-8ABF-4E76-880C-863CA507CA2A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlLpXWEACgkQA/52wvuLgaFMPQCeOLziCvlT18MSeI+ldqQzug83 B6oAoIJb30iRvy0Na/Xxxtk3aFhE5fpd =NSiG -----END PGP SIGNATURE----- --Apple-Mail=_7E6A468F-8ABF-4E76-880C-863CA507CA2A-- From keyupate@cisco.com Wed Jan 29 14:16:12 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2161A02C0 for ; Wed, 29 Jan 2014 14:16:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYck_t8BWCDC for ; Wed, 29 Jan 2014 14:16:07 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id C8FBA1A0056 for ; Wed, 29 Jan 2014 14:16:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=48223; q=dns/txt; s=iport; t=1391033764; x=1392243364; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=Y7lyq6Zu+HVu4ELqh+r80NlftdCpB3XpysOEK6iHqfM=; b=NqYODYTIxzeR+oipgYtm2goSpcmmU/bDTsSo6YEFk9eVqjbwV682FssY H7luB0s9k+kVaJb9B+2m/1pxMgYc4SlcBaPcKkZsKmEDaS6OntkkQRy4V yrAfM7qJeLnjJzcgh+JytszHZ+oDL//EdU7kEoyoUmklOd77bs38Bi7zE Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFABx96VKtJV2c/2dsb2JhbABZgkhEOFa9DoEDFnSCJQEBAQQBAQEXE0ELDAYBCBEDAQEBFgsBBigGCxQJCAIEAQ0Fh3EDEQ2pXpguDYgKEwSMaoEzCwYBPwwBBAYBBgSELgSWPIFsjF6FQYMtgWgBBgIXIg X-IronPort-AV: E=Sophos;i="4.95,744,1384300800"; d="scan'208,217";a="16531310" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-5.cisco.com with ESMTP; 29 Jan 2014 22:16:02 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s0TMG2x0026243 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Jan 2014 22:16:03 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.228]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Wed, 29 Jan 2014 16:16:02 -0600 From: "Keyur Patel (keyupate)" To: "bruno.decraene@orange.com" , Robert Raszuk Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPHT+xkeX0Ff7T2kONFJ6OHVSLvw== Date: Wed, 29 Jan 2014 22:16:01 +0000 Message-ID: In-Reply-To: <6650_1390989061_52E8CF05_6650_399_1_53C29892C857584299CBF5D05346208A070DFED8@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [128.107.163.31] Content-Type: multipart/alternative; boundary="_000_CF0EBE3661404keyupateciscocom_" MIME-Version: 1.0 Cc: "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 22:16:12 -0000 --_000_CF0EBE3661404keyupateciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Bruno, We only generate Notification for invalid length. Apologies for the confusi= on. Attached is the revised text. Regards, Keyur The error handling specified in this section is applicable only when a BGP speaker has received the "Enhanced Route Refresh Capability" from a peer. If the length, excluding the fixed-size message header, of the received ROUTE-REFRESH message with Message Subtype 1 and 2 is not 4, then the BGP speaker MUST send a NOTIFICATION message with the Error Code of "ROUTE-REFRESH Message Error" and the subcode of "Invalid Message Length". The Data field of the NOTIFICATION message MUST contain the complete ROUTE-REFRESH message. When the BGP speaker receives a ROUTE-REFRESH message with a "Message Subtype" field other than 1 or 2, it MUST ignore the received ROUTE- REFRESH message. It SHOULD log an error for further analysis. From: > Date: Wed, 29 Jan 2014 09:51:00 +0000 To: Robert Raszuk >, Keyur Pate= l > Cc: "idr@ietf.org" > Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi all, From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: Wednesday, January 29, 2014 10:15 AM To: Dongjie (Jimmy) Cc: Keyur Patel (keyupate); idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Jimmy and all, I think Enke and Keyur's proposed text with help from Jakob makes the behav= ior simplified and deterministic to hold on BoRR till first EoR is seen. IMHO it should be also spelled out what is the expected sequence error hand= ling here [Bruno] +1. And taking into account possible interaction with draft-ietf-i= dr-bgp-gr-notification BTW: =93When the BGP speaker detects an error while processing a ROUTE-REFRESH m= essage with a non-zero "Message Subtype" field, it MUST send a NOTIFICATION= message with Error Code "ROUTE-REFRESH Message Error".=94 Seems a priori not inline with the recommendation from draft-ietf-grow-ops-= reqs-for-bgp-error-handling (which is to limit the consequences of error ha= ndling). Are we sure that no error condition could be handled in a more fri= endly way? (e.g. if BoRR is not sent following a =93normal route refresh re= quest=94 or if 2 BoRR are sent consecutively=85) Thanks, Regards, Bruno ... I think not following "MUST NOT" shall implicitly result in entire sess= ion drop and complete restart ? Any error code ? Best, R. On Wed, Jan 29, 2014 at 9:22 AM, Dongjie (Jimmy) > wrote: Hi Robert, Agree that in these cases the RRQ cannot be ignored, so postpone may be a b= etter choice. While IMO stop the initial update and start over may delay the initial conv= ergence, and as you said it also relates to update group processing. What = do you think about the new text provided by Keyur? Best regards, Jie From:rraszuk@gmail.com [mailto:rraszuk@gmail.com<= mailto:rraszuk@gmail.com>] On Behalf Of Robert Raszuk Sent: Sunday, January 26, 2014 11:03 PM To: Dongjie (Jimmy) Cc: Keyur Patel (keyupate); Jakob Heitz; idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Jie, I think it actually very easy to say that initial update can not ever guara= ntee that RRQ received during its sending may meet the peer's need. Example 1: SAFI 128 - During receiving initial update from RR to PE new VRF got added = with new RT import. Unfortunately those updates received within initial upd= ate were already dropped as not interesting by the PE. RR must resend full = table after completed initial update. (Of course this is the case where the= re is no RTC and that's why RTC helps a lot here by incremental nature). Example 2: SAFI 1 - Operator has modified inbound policy on EBGP peer during processin= g of incoming updates and those originally were dropped. No soft reconfig i= n set. Conclusion: RRQ can not ever be ignored. Sure they can be delayed or batched (case of m= ultiple peers within the same update/peer group) sending near RRQs (cluster= of PEs got provisioned from central management station). But as Keyur alre= ady mentioned those are rather standard local implementation optimizations. Question: Does it maybe make sense to stop initial update when receiving RRQ from a p= eer and start over ? Of course if peer is part of large update group it wou= ld have to be removed dynamically from it so other members are not delayed.= In any case I think this does not impact the spec but the implementation. Cheers, R. On Sun, Jan 26, 2014 at 7:13 PM, Dongjie (Jimmy) > wrote: Hi Keyur, Jakob, Agree that "postpone" may be better. The point is we could avoid the compli= cated cases/considerations of performing route refresh during initial updat= e:) For "ignore", I was thinking of scenarios in which the route refresh requir= ement may already be met by the initial update, while I'd admit it is hard = to say... Best regards, Jie -----Original Message----- From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] Sent: Sunday, January 26, 2014 8:30 PM To: Jakob Heitz; Dongjie (Jimmy) Cc: idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Jie, I agree with Jakob. You could make it *an implementation behavior* to postp= one the route refresh reply. Regards, Keyur On 1/26/14 1:29 AM, "Jakob Heitz" > wrote: >You can definitely not ignore it, but you could postpone it. > >-- >Jakob Heitz. > >> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" > >>wrote: >> >> After reading the analyses in this thread, my personal feeling is >>maybe we should avoid the interleaving between GR initial update and >>route refresh/enhanced route refresh, since the initial update is just >>sending the whole Adj-RIB-Out, there is no obvious advantage to start >>a route refresh/enhance route refresh during it. So a speaker should >>ignore the RRQ received during the initial update. Thoughts? >> >> Best regards, >> Jie >> >> -----Original Message----- >> From: Idr [mailto:idr-bounces@ietf.org] On = Behalf Of Jakob Heitz >> Sent: Saturday, January 25, 2014 10:48 PM >> To: Chris Hall; idr@ietf.org >> Subject: Re: [Idr] WG LC for >> draft-ietf-idr-bgp-enhanced-route-refresh >> >> RFCs are written for coders "practiced" in the art". >> If anyone sends an EoRR before the adj-RIB-out is fully populated, >>then it's a BUG. >> This does not need to be said. >> >> Personally, I believe a route refresh request should not be honored >>until GR is complete. >> Also, I don't believe a timer for the receipt of EoRR is necessary, >>because the EoRR is guaranteed. >> Guaranteed means "unless the session drops first". >> -- >> >> Jakob Heitz. >> >> ________________________________________ >> From: Chris Hall [chris.hall@highwayman.com] >> Sent: Saturday, 25 January 2014 11:27 AM >> To: idr@ietf.org >> Cc: Jakob Heitz >> Subject: RE: [Idr] WG LC for >> draft-ietf-idr-bgp-enhanced-route-refresh >> >> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): >> ... >>> Silence means don't do it. >> >> Hmmm.... as a principle I'm more comfortable with "that which isn't >>prohibited is permitted".... >> >>> You would definitely NOT want BoRR to flush old stales. >> >> ....but, given the definite requirement, and given that the current >>precedent for "marking stale" does flush old stale, then a few words >>for the avoidance of doubt ? >> >>> Restarting the timer might be a good idea. >> >> I dunno... a route which remains stale for "a long time" is, of >>course, a candidate for being withdrawn: so having started a timer the >>first time things are set stale, I would avoid extending that -- at >>least for Graceful Restart, where the whole withdraw thing has been "on-h= old" >>since the last session failed. For route-refresh I guess there's more >>of a presumption that stale routes will be refreshed sooner or later, >>and in the meantime they remain good. So if the route-refresh is >>(repeatedly) restarted for some reason, perhaps it is more reasonable >>to extend the flush deadline -- but avoid doing this indefinitely ? >> >> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I have >>built in Quagga prioritise route changes (pending changes and any that >>occur during the refresh) over refresh updates. This makes it more >>likely that remaining stale routes are still good. But the other end >>cannot know that. >> >> The paragraph in the draft discussing the "entire Adj-RIB-Out" >>defines that to be the entries present "at the start of the route >>refresh operation", and observes that these comprise both reachable >>and unreachable routes. [An "of" after "comprise" sets teeth on edge, >>BTW.] I'm really not sure what this paragraph is trying to tell me. >> The reference to unreachable routes appears to suggest that pending >>withdraws should be sent as part of the refresh -- so not left to the >>EoRR to implement at the end. The point at which the EoRR is sent is >>defined such that it excludes any Adj-RIB-Out entries added after the >>route-refresh started, but includes any which are changed during the >>process. It seems reasonable to delay any brand new reachable >>prefixes until after all previously announced ones have been refreshed >>and the EoRR sent -- if that's the intent here. Changes which occur >>before the refresh gets to a given entry are pretty naturally swept up >>by the refresh. Changes which occur after the refresh has gone past, >>could/should be deferred to after the EoRR ? Does it make a >>difference if the change is a withdraw ? (Of course MRAI may kick in her= e. Ah. >>MRAI and route-refresh, there's a topic !) >> >> I think the essence of the rule is that the EoRR should be sent once >>all prefixes previously advertised to the peer as reachable have been >>refreshed, ie announced or withdrawn (at least) once. Or, perhaps >>more strictly, not *before* those prefixes have *all* been announced >>once -- given that the EoRR will promptly bang un-advertised stuff on the= head. >>Even more strictly perhaps: not send EoRR *before* any withdraws >>implied by it are required or desirable. >> >> Depending on the implementation, a given sender may or may not be >>able to determine the minimum set of updates required before sending EoRR= . >> >> If the refresh operation takes a long time, there may be good >>routeing reasons to arrange for some route changes to be sent to the peer= "early" >>-- that is to send announcements which do not contribute to the >>refresh, but which are important enough to warrant delaying the end of >>the refresh. That could be a matter for recommendation(s) in the standar= d. >> >> NB: given that the timing of the EoRR is tied to the state of the >>Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. At >>the beginning of the initial update, the Restarting and Receiving >>speakers have: >> >> Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out >> >> Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In >> >> Now suppose (bonkers or otherwise) the receiving speaker sends an RRQ >>part way through the initial update. The restarting speaker responds >>with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specification. >> The receiving speaker sees the EoRR, and flushes stale. >>Unfortunately, if the restarting speaker has not yet fully populated >>its Adj-RIB-Out, then many further routes will be sent before the EoR >>falls due -- but the receiving speaker has already flushed their tiny >>posteriors :-( >> >> I am coming to the view that route-refresh during a Graceful Restart >>initial update is a horse of a different colour altogether. >> >> [So the assumption that EoRR and EoR are triggered by the same thing >>was completely wrong, and I apologise for it.] >> >> Chris >> >> _______________________________________________ >> 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 ___________________________________________________________________________= ______________________________________________ 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, 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 authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_CF0EBE3661404keyupateciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <11A3922281EF6E478DF3874345BC01C5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Bruno,

We only generate Notification for invalid length. Apologies for the co= nfusion. Attached is the revised text.

Regards,
Keyur

<snip>
The error handling specified in this section is applicable only when
   a BGP speaker has received the "Enhanced Route Refre= sh Capability"
   from a peer.

   If the length, excluding the fixed-size message header, o= f the
   received ROUTE-REFRESH message with Message Subtype 1 and= 2 is not 4,
   then the BGP speaker MUST send a NOTIFICATION message wit= h the Error
   Code of "ROUTE-REFRESH Message Error" and the s= ubcode of "Invalid
   Message Length".  The Data field of the NOTIFIC= ATION message MUST
   contain the complete ROUTE-REFRESH message.

   When the BGP speaker receives a ROUTE-REFRESH message wit= h a "Message
   Subtype" field other than 1 or 2, it MUST ignore the= received ROUTE-
   REFRESH message.  It SHOULD log an error for further= analysis.

<snip>

From: <bruno.decraene@orange.com>
Date: Wed, 29 Jan 2014 09:51:00 = 3;0000
To: Robert Raszuk <robert@raszuk.net>, Keyur Patel <keyupate@cisco.com>
Cc: "idr@ietf.org" <idr@ietf.= org>
Subject: RE: [Idr] WG LC for draft-= ietf-idr-bgp-enhanced-route-refresh

Hi all,

 

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Wednesday, January 29, 2014 10:15 AM
To: Dongjie (Jimmy)
Cc: Keyur Patel (keyupate); idr@ietf= .org
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refre= sh

 

Hi Jimm= y and all,

&n= bsp;

I think= Enke and Keyur's proposed text with help from Jakob makes the behavior sim= plified and deterministic to hold on BoRR till first EoR is seen.

&n= bsp;

IMHO it= should be also spelled out what is the expected sequence error handling he= re

 

[Bruno] +1. &nb= sp;And taking into account possible interaction with draft-ietf-idr-bgp-gr-= notification

 

BTW:

=93When the BGP spe= aker detects an error while processing a ROUTE-REFRESH message with a non-z= ero "Message Subtype" field, it MUST send a NOTIFICATION message with Error Code "ROUTE-REFRESH Message Error&q= uot;.=94

 

Seems a priori not = inline with the recommendation from draft-ietf-grow-ops-reqs-for-bgp-error-= handling (which is to limit the consequences of error handling). Are we sure that no error condition could be handled i= n a more friendly way? (e.g. if BoRR is not sent following a =93normal rout= e refresh request=94 or if 2 BoRR are sent consecutively=85)

 

Thanks,<= /span>

Regards,=

Bruno

 

 

... I think not following "MU= ST NOT" shall implicitly result in entire session drop and complete re= start ? Any error code ?

&n= bsp;

Best, R.

&n= bsp;

 

On Wed, Jan 29, 2014 at 9:22 AM, Dongjie (Jimmy) <= ;jie.dong@huawei.c= om> wrote:

Hi Robert,

 

Agree that in these cases the R= RQ cannot be ignored, so postpone may be a better choice.

 

While IMO stop the initial upda= te and start over may delay the initial convergence, and as you said  it also relates to update group process= ing. What do you think about the new text provided by Keyur?

 

Best regards,

Jie

 

From:rraszuk@gmail.com [mailto:rraszuk@gma= il.com] On Behalf Of Robert Raszuk
Sent: Sunday, January 26, 2014 11:03 PM
To: Dongjie (Jimmy)
Cc: Keyur Patel (keyupate); Jakob Heitz; idr@ietf.org


Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refre= sh

 

Hi Jie= ,

 =

I thin= k it actually very easy to say that initial update can not ever guarantee t= hat RRQ received during its sending may meet the peer's need.

 =

Exampl= e 1:

 =

SAFI 1= 28 - During receiving initial update from RR to PE new VRF got added with n= ew RT import. Unfortunately those updates received within initial update were already dropped as not interesting by = the PE. RR must resend full table after completed initial update. (Of cours= e this is the case where there is no RTC and that's why RTC helps a lot her= e by incremental nature). 

 =

Exampl= e 2: 

 =

SAFI 1= - Operator has modified inbound policy on EBGP peer during processing of i= ncoming updates and those originally were dropped. No soft reconfig in set. 

 =

Conclu= sion:

 =

RRQ ca= n not ever be ignored. Sure they can be delayed or batched (case of multipl= e peers within the same update/peer group) sending near RRQs (cluster of PEs got provisioned from central management = station). But as Keyur already mentioned those are rather standard local im= plementation optimizations. 

 =

Questi= on:

 =

Does i= t maybe make sense to stop initial update when receiving RRQ from a peer an= d start over ? Of course if peer is part of large update group it would have to be removed dynamically from it so o= ther members are not delayed. In any case I think this does not impact the = spec but the implementation.

 =

Cheers= ,
R.

 =

 =

 

On Sun, Jan 26, 2014 at 7:13 PM, Dongjie (Jim= my) <jie.dong@h= uawei.com> wrote:

Hi Keyur, Jakob,

Agree that "postpone" may be better. The point is we could avoid = the complicated cases/considerations of performing route refresh during ini= tial update:)

For "ignore", I was thinking of scenarios in which the route refr= esh requirement may already be met by the initial update, while I'd admit i= t is hard to say...



Best regards,
Jie

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

From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] Sent: Sunday, January 26, 2014 8:30 PM
To: Jakob Heitz; Dongjie (Jimmy)
Cc: idr@ietf.org
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Jie,

I agree with Jakob. You could make it *an implementation behavior* to postp= one the route refresh reply.


Regards,
Keyur

On 1/26/14 1:29 AM, "Jakob Heitz" <jakob.heitz@ericsson.com> wrote:<= br>
>You can definitely not ignore it, but you could postpone it.
>
>--
>Jakob Heitz.
>
>> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" <jie.dong@huawei.com>
>>wrote:
>>
>> After reading the analyses in this thread, my personal feeling is<= br> >>maybe we should avoid the interleaving between GR initial update an= d
>>route refresh/enhanced route refresh, since the initial update is j= ust
>>sending the whole Adj-RIB-Out, there is no obvious advantage to sta= rt
>>a route refresh/enhance route refresh during it. So a speaker shoul= d
>>ignore the RRQ received during the initial update. Thoughts?
>>
>> Best regards,
>> Jie
>>
>> -----Original Message-----
>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz
>> Sent: Saturday, January 25, 2014 10:48 PM
>> To: Chris Hall; = idr@ietf.org
>> Subject: Re: [Idr] WG LC for
>> draft-ietf-idr-bgp-enhanced-route-refresh
>>
>> RFCs are written for coders "practiced" in the art"= .
>> If anyone sends an EoRR before the adj-RIB-out is fully populated,=
>>then it's a BUG.
>> This does not need to be said.
>>
>> Personally, I believe a route refresh request should not be honore= d
>>until GR is complete.
>> Also, I don't believe a timer for the receipt of EoRR is necessary= ,
>>because the EoRR is guaranteed.
>> Guaranteed means "unless the session drops first".
>> --
>>
>> Jakob Heitz.
>>
>> ________________________________________
>> From: Chris Hall [chris.hall@highwayman.com]
>> Sent: Saturday, 25 January 2014 11:27 AM
>> To: idr@ietf.org=
>> Cc: Jakob Heitz
>> Subject: RE: [Idr] WG LC for
>> draft-ietf-idr-bgp-enhanced-route-refresh
>>
>> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37):
>> ...
>>> Silence means don't do it.
>>
>> Hmmm.... as a principle I'm more comfortable with "that which= isn't
>>prohibited is permitted"....
>>
>>> You would definitely NOT want BoRR to flush old stales.
>>
>> ....but, given the definite requirement, and given that the curren= t
>>precedent for "marking stale" does flush old stale, then = a few words
>>for the avoidance of doubt ?
>>
>>> Restarting the timer might be a good idea.
>>
>> I dunno... a route which remains stale for "a long time"= is, of
>>course, a candidate for being withdrawn: so having started a timer = the
>>first time things are set stale, I would avoid extending that -- at=
>>least for Graceful Restart, where the whole withdraw thing has been= "on-hold"
>>since the last session failed.  For route-refresh I guess ther= e's more
>>of a presumption that stale routes will be refreshed sooner or late= r,
>>and in the meantime they remain good.  So if the route-refresh= is
>>(repeatedly) restarted for some reason, perhaps it is more reasonab= le
>>to extend the flush deadline -- but avoid doing this indefinitely ?=
>>
>> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I ha= ve
>>built in Quagga prioritise route changes (pending changes and any t= hat
>>occur during the refresh) over refresh updates.  This makes it= more
>>likely that remaining stale routes are still good.  But the ot= her end
>>cannot know that.
>>
>> The paragraph in the draft discussing the "entire Adj-RIB-Out= "
>>defines that to be the entries present "at the start of the ro= ute
>>refresh operation", and observes that these comprise both reac= hable
>>and unreachable routes.  [An "of" after "compri= se" sets teeth on edge,
>>BTW.]  I'm really not sure what this paragraph is trying to te= ll me.
>> The reference to unreachable routes appears to suggest that pendin= g
>>withdraws should be sent as part of the refresh -- so not left to t= he
>>EoRR to implement at the end.  The point at which the EoRR is = sent is
>>defined such that it excludes any Adj-RIB-Out entries added after t= he
>>route-refresh started, but includes any which are changed during th= e
>>process.  It seems reasonable to delay any brand new reachable=
>>prefixes until after all previously announced ones have been refres= hed
>>and the EoRR sent -- if that's the intent here.  Changes which= occur
>>before the refresh gets to a given entry are pretty naturally swept= up
>>by the refresh.  Changes which occur after the refresh has gon= e past,
>>could/should be deferred to after the EoRR ?  Does it make a >>difference if the change is a withdraw ?  (Of course MRAI may = kick in here.  Ah.
>>MRAI and route-refresh, there's a topic !)
>>
>> I think the essence of the rule is that the EoRR should be sent on= ce
>>all prefixes previously advertised to the peer as reachable have be= en
>>refreshed, ie announced or withdrawn (at least) once.  Or, per= haps
>>more strictly, not *before* those prefixes have *all* been announce= d
>>once -- given that the EoRR will promptly bang un-advertised stuff = on the head.
>>Even more strictly perhaps: not send EoRR *before* any withdraws >>implied by it are required or desirable.
>>
>> Depending on the implementation, a given sender may or may not be<= br> >>able to determine the minimum set of updates required before sendin= g EoRR.
>>
>> If the refresh operation takes a long time, there may be good
>>routeing reasons to arrange for some route changes to be sent to th= e peer "early"
>>-- that is to send announcements which do not contribute to the
>>refresh, but which are important enough to warrant delaying the end= of
>>the refresh.  That could be a matter for recommendation(s) in = the standard.
>>
>> NB: given that the timing of the EoRR is tied to the state of the<= br> >>Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. &= nbsp;At
>>the beginning of the initial update, the Restarting and Receiving >>speakers have:
>>
>>  Restarting:  Empty Adj-RIB-In   Empty Adj-RIB-Out<= br> >>
>>  Receiving:   Empty Adj-RIB-Out  Stale Adj-RIB-In >>
>> Now suppose (bonkers or otherwise) the receiving speaker sends an = RRQ
>>part way through the initial update.  The restarting speaker r= esponds
>>with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specifica= tion.
>> The receiving speaker sees the EoRR, and flushes stale.
>>Unfortunately, if the restarting speaker has not yet fully populate= d
>>its Adj-RIB-Out, then many further routes will be sent before the E= oR
>>falls due -- but the receiving speaker has already flushed their ti= ny
>>posteriors :-(
>>
>> I am coming to the view that route-refresh during a Graceful Resta= rt
>>initial update is a horse of a different colour altogether.
>>
>> [So the assumption that EoRR and EoR are triggered by the same thi= ng
>>was completely wrong, and I apologise for it.]
>>
>> Chris
>>
>> _______________________________________________
>> 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
htt= ps://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,
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 authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_CF0EBE3661404keyupateciscocom_-- From sairay@cisco.com Wed Jan 29 17:38:32 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A9A1A03EA; Wed, 29 Jan 2014 17:38:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovJZyTyaLbB3; Wed, 29 Jan 2014 17:38:25 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 02C5F1A03CC; Wed, 29 Jan 2014 17:38:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=63000; q=dns/txt; s=iport; t=1391045902; x=1392255502; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jsEC3nmI39ur95RZ/nZ8GOn9XMWGhBlLxujSv6DSvTI=; b=fDza+5XDuWGJZRGGgX0UcSOcFJTcfRx7ctH0c0K2zGOqug0L85o9/Enl yFuJtDT07B9R2AOeMvxXoQAX0QXP6XRCXbt0fvMLlVExRFdjTOMjHk336 7ZMk9x+6EtopoNH980b353F+tW55ih6C8z0FipuvGEcYCcT/Icc5AOwut g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmIFABSs6VKtJXG+/2dsb2JhbABZgkhEOFe9G4ECFnSCJQEBAQMBAQEBFxNBCwUHBAIBCBEDAQEBCxYBBgcnCxQJCAIEDgUIh3UIDalVogMTBI5OIA0EBgEGgx6BFASUQJYHgUCBbYFoBzs X-IronPort-AV: E=Sophos;i="4.95,745,1384300800"; d="scan'208,217";a="16563908" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-5.cisco.com with ESMTP; 30 Jan 2014 01:38:18 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0U1cI4O004706 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Jan 2014 01:38:18 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.24]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Wed, 29 Jan 2014 19:38:18 -0600 From: "Saikat Ray (sairay)" To: Thomas Mangin Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPF5Kdim6y2NtdXEOlCixBVCgqkZqRnDwAgAFEnwCAAAwAgIAAC4cAgAARhoCAABveAIAABfyAgAAe+ICAABsuAIABU5kAgAAEDoCAAX73AIAABbuAgAHS7QCAAuS1AIAABIUAgAAC0YCAAAG5gIAAB0kAgAACCYCAAAM5gIAACciAgAAUgwCAACB8AP//m/cwgADYwYCAAML6kA== Date: Thu, 30 Jan 2014 01:38:17 +0000 Message-ID: <8ED5B0B0F5B4854A912480C1521F973A11AFCCA6@xmb-rcd-x13.cisco.com> References: <010801cf1c8c$6b1a0420$414e0c60$@ndzh.com> <8ED5B0B0F5B4854A912480C1521F973A11AFBD56@xmb-rcd-x13.cisco.com> <6D84FB20-2A48-4830-92F5-C81C5F4AA36A@exa-networks.co.uk> In-Reply-To: <6D84FB20-2A48-4830-92F5-C81C5F4AA36A@exa-networks.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.166.25] Content-Type: multipart/alternative; boundary="_000_8ED5B0B0F5B4854A912480C1521F973A11AFCCA6xmbrcdx13ciscoc_" MIME-Version: 1.0 Cc: "idr@ietf.org" , "Keyur Patel \(keyupate\)" , "idr-bounces@ietf.org" , Susan Hares Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 01:38:33 -0000 --_000_8ED5B0B0F5B4854A912480C1521F973A11AFCCA6xmbrcdx13ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The route may have been advertised before (and not (yet) withdrawn). Consid= er the example: +---+ +---+ | A +-----+ B | +---+ +---+ t=3D0: A sends three prefixes: 1.1.1.1/32, 2.2.2.2/32, 3.3.3.3/32, to B. t=3D1: B sends an (enhanced) route-refresh request to A. t=3D2: A sends BoRR to B. t=3D3: A sends 1.1.1.1/32 and 2.2.2.2/32 to B t=3D4: A sends EoRR to B. At this point, both A and B MUST treat 3.3.3.3/32 as withdrawn even though = there was no explicit withdraw sent for it. That means, A doesn't need to s= end an explicit withdraw for 3.3.3.3/32, and B must delete 3.3.3.3/32's pat= h from A. This is the core semantics of BoRR and EoRR and it takes care of all cases.= This implies, e.g., if the sender A want to ensure that a particular prefi= x, x.y.z.w/n, is not considered withdrawn by the receiver, then A MUST adve= rtise x.y.z.w/n following any BoRR (even in nested cases) *before* any EoRR= . -----Original Message----- From: Thomas Mangin [mailto:thomas.mangin@exa-networks.co.uk] Sent: Tuesday, January 28, 2014 11:50 PM To: Saikat Ray (sairay) Cc: Susan Hares; Jeff Tantsura; Keyur Patel (keyupate); Jakob Heitz; idr-bo= unces@ietf.org; idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hello Saikat, Why "both by the sender", if the route was not announced it is clearly with= drawn on the sender side and by definition if a route is not in the RR it h= as to be withdrawn - that said saying it can not harm .. Thomas Sent from my iPad > On 29 Jan 2014, at 01:03, "Saikat Ray \(sairay\)" > wrote: > > The draft should add a line mandating the actual semantics (instead of/in= addition to the procedures of mark-and-sweep). Something along the line: > > "Any route for which no update has been sent between a BoRR and the follo= wing EoRR MUST be considered withdrawn by both the sender and the receiver.= " > > The rest is really implementation (how to handle nested BoRR/EoRR or GR E= oR, etc.), IMHO. > > I support the draft, BTW. > > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares > Sent: Tuesday, January 28, 2014 4:53 PM > To: 'Jeff Tantsura'; Keyur Patel (keyupate); 'Jakob Heitz'; 'Thomas > Mangin'; idr-bounces@ietf.org > Cc: idr@ietf.org > Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh > > Any other comments? (support/discussion accepted) > > Sue Hares > > PS - Keyur - spin a draft with this change and end it to me. > > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jeff Tantsura > Sent: Tuesday, January 28, 2014 5:56 PM > To: Keyur Patel (keyupate); Jakob Heitz; Thomas Mangin; > idr-bounces@ietf.org > Cc: idr@ietf.org > Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh > > I support the wording below. > > Cheers, > Jeff > > > -----Original Message----- > From: "keyupate@cisco.com" > > Date: Tuesday, January 28, 2014 1:43 PM > To: "keyupate@cisco.com" >, Jakob Heitz >, Thomas Mangin >, "idr-bounces@ietf.org" > > > Cc: "idr@ietf.org" > > Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh > >> Hi Jakob, >> >> How about the following (based on your suggestion): >> >> For a BGP speaker that supports the BGP Graceful Restart specified in >> [RFC4724] , it MUST NOT send a BoRR for an AFI/SAFI to a neighbor >> before it sends the EOR for the AFI/SAFI to the neighbor. This >> procedure would help the neighbor avoid the premature cleanup of >> stale routes. >> >> >> This would help simplify receiver side implementation wrt GR and >> Enhanced RR. :) >> >> Regards, >> Keyur >> >>> On 1/28/14 1:08 PM, "Keyur Patel (keyupate)" > wrote: >>> >>> Sure! I am saying you can simplify the implementation by simply >>> delaying the servicing of the route refresh reply till the >>> generation of > an EOR. >>> >>> Question is do we allow the text to be flexible enough to cover the >>> other case. :) >>> >>> Regards, >>> Keyur >>> >>>> On 1/28/14 12:56 PM, "Jakob Heitz" > wrote: >>>> >>>> Could we please simplify this a bit, not to force implementations >>>> to use different stale bits? >>>> >>>> Thanks, >>>> Jakob. >>>> >>>> -----Original Message----- >>>> From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] >>>> Sent: Tuesday, January 28, 2014 12:49 PM >>>> To: Jakob Heitz; Thomas Mangin; idr-bounces@ietf.org >>>> Cc: idr@ietf.org >>>> Subject: Re: [Idr] WG LC for >>>> draft-ietf-idr-bgp-enhanced-route-refresh >>>> >>>> >>>> >>>>> On 1/28/14 12:23 PM, "Jakob Heitz" > wrote: >>>>> >>>>> the order BoRR, EoR, EoRR allows this possible scenario: >>>>> >>>>> Suppose 2 routes exist :1.1.1.1/32, 2.2.2.2/32 The order could now be= : >>>>> . start session >>>>> . send 1.1.1.1/32 >>>>> . receive route refresh request. >>>>> . send BoRR >>>>> . send 2.2.2.2/32 >>>>> . send EoR >>>>> . send 1.1.1.1/32 >>>>> . send EoRR >>>>> >>>>> On receipt of EoR, the receiver could delete stales, deleting >>>>> 1.1.1.1/32. >>>> >>>> Not if you use different flags/bits to mark them stale? >>>> >>>> Implementations could choose to always postpone the route refresh >>>> reply and get the same behavior? >>>> >>>> Regards, >>>> Keyur >>>> >>>>> >>>>> Thanks, >>>>> Jakob. >>>>> >>>>> -----Original Message----- >>>>> From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] >>>>> Sent: Tuesday, January 28, 2014 12:17 PM >>>>> To: Jakob Heitz; Thomas Mangin; idr-bounces@ietf.org >>>>> Cc: idr@ietf.org >>>>> Subject: Re: [Idr] WG LC for >>>>> draft-ietf-idr-bgp-enhanced-route-refresh >>>>> >>>>> The order: BoRR, EoR, EoRR lets an implementation do both, merge >>>>> route refresh reply with an initial table announcement or delay >>>>> the route refresh replies. As long as EoR is sent before EoRR >>>>> there should be no issue right? >>>>> >>>>> Regards, >>>>> Keyur >>>>>> On 1/28/14 12:06 PM, "Jakob Heitz" > wrote: >>>>>> >>>>>> Enke's text allows the order: BoRR, EoR, EoRR. >>>>>> >>>>>> Could we change Enke's text from >>>>>> "it MUST NOT send an EoRR" to >>>>>> "it MUST NOT send an BoRR" >>>>>> >>>>>> Thanks, >>>>>> Jakob. >>>>>> >>>>>> -----Original Message----- >>>>>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Keyur Patel >>>>>> (keyupate) >>>>>> Sent: Tuesday, January 28, 2014 11:51 AM >>>>>> To: Thomas Mangin; idr-bounces@ietf.org >>>>>> Cc: idr@ietf.org >>>>>> Subject: Re: [Idr] WG LC for >>>>>> draft-ietf-idr-bgp-enhanced-route-refresh >>>>>> >>>>>> Hi Jacob, Thomas, >>>>>> >>>>>> Am ok with implementations delaying the servicing of route >>>>>> refresh request. Enke's suggested text addresses the concern. >>>>>> >>>>>> Best Regards, >>>>>> Keyur >>>>>> >>>>>> On 1/26/14 3:39 PM, "Thomas Mangin" >>>>>> > >>>>>> wrote: >>>>>> >>>>>>> Damn, time to practice then :) >>>>>>> >>>>>>> Joke apart, I agree with this post. The feature should not be >>>>>>> used ( and ignored ) until the initial route exchange has been comp= leted. >>>>>>> >>>>>>> If the session drops, I would expect the router to cancel any RR >>>>>>> which was ongoing as the AdjRIBOut is going to be retransmitted >>>>>>> anyway. >>>>>>> >>>>>>> Thomas >>>>>>> >>>>>>> Sent from my iPad >>>>>>> >>>>>>>> On 25 Jan 2014, at 19:48, Jakob Heitz >>>>>>>> > >>>>>>>> wrote: >>>>>>>> >>>>>>>> RFCs are written for coders "practiced" in the art". >>>>>>>> If anyone sends an EoRR before the adj-RIB-out is fully >>>>>>>> populated, then it's a BUG. >>>>>>>> This does not need to be said. >>>>>>>> >>>>>>>> Personally, I believe a route refresh request should not be >>>>>>>> honored until GR is complete. >>>>>>>> Also, I don't believe a timer for the receipt of EoRR is >>>>>>>> necessary, because the EoRR is guaranteed. >>>>>>>> Guaranteed means "unless the session drops first". >>>>>>>> -- >>>>>>>> >>>>>>>> Jakob Heitz. >>>>>>>> >>>>>>>> ________________________________________ >>>>>>>> From: Chris Hall [chris.hall@highwayman.com] >>>>>>>> Sent: Saturday, 25 January 2014 11:27 AM >>>>>>>> To: idr@ietf.org >>>>>>>> Cc: Jakob Heitz >>>>>>>> Subject: RE: [Idr] WG LC for >>>>>>>> draft-ietf-idr-bgp-enhanced-route-refresh >>>>>>>> >>>>>>>> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): >>>>>>>> ... >>>>>>>>> Silence means don't do it. >>>>>>>> >>>>>>>> Hmmm.... as a principle I'm more comfortable with "that which >>>>>>>> isn't prohibited is permitted".... >>>>>>>> >>>>>>>>> You would definitely NOT want BoRR to flush old stales. >>>>>>>> >>>>>>>> ....but, given the definite requirement, and given that the >>>>>>>> current precedent for "marking stale" does flush old stale, >>>>>>>> then a few words for the avoidance of doubt ? >>>>>>>> >>>>>>>>> Restarting the timer might be a good idea. >>>>>>>> >>>>>>>> I dunno... a route which remains stale for "a long time" is, of >>>>>>>> course, a candidate for being withdrawn: so having started a >>>>>>>> timer the first time things are set stale, I would avoid >>>>>>>> extending that >>>>>>>> -- at least for Graceful Restart, where the whole withdraw >>>>>>>> thing has been "on-hold" since the last session failed. For >>>>>>>> route-refresh I guess there's more of a presumption that stale >>>>>>>> routes will be refreshed sooner or later, and in the meantime >>>>>>>> they remain good. So if the route-refresh is (repeatedly) >>>>>>>> restarted for some reason, perhaps it is more reasonable to >>>>>>>> extend the flush deadline -- but avoid doing this indefinitely ? >>>>>>>> >>>>>>>> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I >>>>>>>> have built in Quagga prioritise route changes (pending changes >>>>>>>> and any that occur during the refresh) over refresh updates. >>>>>>>> This makes it more likely that remaining stale routes are still > good. >>>>>>>> But the other end cannot know that. >>>>>>>> >>>>>>>> The paragraph in the draft discussing the "entire Adj-RIB-Out" >>>>>>>> defines that to be the entries present "at the start of the >>>>>>>> route refresh operation", and observes that these comprise both >>>>>>>> reachable and unreachable routes. [An "of" after "comprise" >>>>>>>> sets teeth on edge, BTW.] I'm really not sure what this >>>>>>>> paragraph is trying to tell me. >>>>>>>> The reference to unreachable routes appears to suggest that >>>>>>>> pending withdraws should be sent as part of the refresh -- so >>>>>>>> not left to the EoRR to implement at the end. The point at >>>>>>>> which the EoRR is sent is defined such that it excludes any >>>>>>>> Adj-RIB-Out entries added after the route-refresh started, but >>>>>>>> includes any which are changed during the process. It seems >>>>>>>> reasonable to delay any brand new reachable prefixes until >>>>>>>> after all previously announced ones have been refreshed and the >>>>>>>> EoRR sent -- if that's the > intent here. >>>>>>>> Changes which occur before the refresh gets to a given entry >>>>>>>> are pretty naturally swept up by the refresh. Changes which >>>>>>>> occur after the refresh has gone past, could/should be deferred >>>>>>>> to after the EoRR ? >>>>>>>> Does it make a difference if the change is a withdraw ? (Of >>>>>>>> course MRAI may kick in here. Ah. MRAI and route-refresh, >>>>>>>> there's a topic >>>>>>>> !) >>>>>>>> >>>>>>>> I think the essence of the rule is that the EoRR should be sent >>>>>>>> once all prefixes previously advertised to the peer as >>>>>>>> reachable have been refreshed, ie announced or withdrawn (at leas= t) once. >>>>>>>> Or, perhaps more strictly, not *before* those prefixes have >>>>>>>> *all* been announced once -- given that the EoRR will promptly >>>>>>>> bang un-advertised stuff on the head. Even more strictly >>>>>>>> perhaps: not send EoRR *before* any withdraws implied by it are >>>>>>>> required or desirable. >>>>>>>> >>>>>>>> Depending on the implementation, a given sender may or may not >>>>>>>> be able to determine the minimum set of updates required before >>>>>>>> sending EoRR. >>>>>>>> >>>>>>>> If the refresh operation takes a long time, there may be good >>>>>>>> routeing reasons to arrange for some route changes to be sent >>>>>>>> to the peer "early" -- that is to send announcements which do >>>>>>>> not contribute to the refresh, but which are important enough >>>>>>>> to warrant delaying the end of the refresh. That could be a >>>>>>>> matter for >>>>>>>> recommendation(s) in the standard. >>>>>>>> >>>>>>>> NB: given that the timing of the EoRR is tied to the state of >>>>>>>> the Adj-RIB-Out, I'm not sure about the Graceful Restart > assumptions. >>>>>>>> At the beginning of the initial update, the Restarting and >>>>>>>> Receiving speakers have: >>>>>>>> >>>>>>>> Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out >>>>>>>> >>>>>>>> Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In >>>>>>>> >>>>>>>> Now suppose (bonkers or otherwise) the receiving speaker sends >>>>>>>> an RRQ part way through the initial update. The restarting >>>>>>>> speaker responds with BoRR, everything in its Adj-RIB-Out, and >>>>>>>> EoRR -- per specification. The receiving speaker sees the >>>>>>>> EoRR, and flushes stale. Unfortunately, if the restarting >>>>>>>> speaker has not yet fully populated its Adj-RIB-Out, then many >>>>>>>> further routes will be sent before the EoR falls due -- but the >>>>>>>> receiving speaker has already flushed their tiny posteriors :-( >>>>>>>> >>>>>>>> I am coming to the view that route-refresh during a Graceful >>>>>>>> Restart initial update is a horse of a different colour altogether= . >>>>>>>> >>>>>>>> [So the assumption that EoRR and EoR are triggered by the same >>>>>>>> thing was completely wrong, and I apologise for it.] >>>>>>>> >>>>>>>> Chris >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >> >> _______________________________________________ >> 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_8ED5B0B0F5B4854A912480C1521F973A11AFCCA6xmbrcdx13ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The route may have been advertised before (and no= t (yet) withdrawn). Consider the example:

 

+---+     +---+

| A +-----+ B |

+---+     +---+

 

t=3D0: A sends three prefixes: 1.1.1.1/32, 2.2.2.= 2/32, 3.3.3.3/32, to B.

t=3D1: B sends an (enhanced) route-refresh reques= t to A.

t=3D2: A sends BoRR to B.

t=3D3: A sends 1.1.1.1/32 and 2.2.2.2/32 to B

t=3D4: A sends EoRR to B.

 

At this point, both A and B MUST treat 3.3.3.3/32= as withdrawn even though there was no explicit withdraw sent for it. That = means, A doesn’t need to send an explicit withdraw for 3.3.3.3/32, an= d B must delete 3.3.3.3/32’s path from A.

 

This is the core semantics of BoRR and EoRR and i= t takes care of all cases. This implies, e.g., if the sender A want to ensu= re that a particular prefix, x.y.z.w/n, is not considered withdrawn by the = receiver, then A MUST advertise x.y.z.w/n following any BoRR (even in nested cases) *before* any EoRR.

 

-----Original Message-----
From: Thomas Mangin [mailto:thomas.mangin@exa-networks.co.uk]
Sent: Tuesday, January 28, 2014 11:50 PM
To: Saikat Ray (sairay)
Cc: Susan Hares; Jeff Tantsura; Keyur Patel (keyupate); Jakob Heitz; idr-bo= unces@ietf.org; idr@ietf.org
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

 

Hello Saikat,

 

Why "both by the sender", if the route = was not announced it is clearly withdrawn on the sender side and by definit= ion if a route is not in the RR it has to be withdrawn - that said saying i= t can not harm ..

 

Thomas

 

Sent from my iPad

 

> On 29 Jan 2014, at 01:03, "Saikat Ray \= (sairay\)" <sairay@cisco.com> wrote:

>

> The draft should add a line mandating the ac= tual semantics (instead of/in addition to the procedures of mark-and-sweep)= . Something along the line:

>

> "Any route for which no update has been= sent between a BoRR and the following EoRR MUST be considered withdrawn by= both the sender and the receiver."

>

> The rest is really implementation (how to ha= ndle nested BoRR/EoRR or GR EoR, etc.), IMHO.

>

> I support the draft, BTW.

>

> -----Original Message-----

> From: Idr [mailto:idr-bou= nces@ietf.org] On Behalf Of Susan Hares

> Sent: Tuesday, January 28, 2014 4:53 PM=

> To: 'Jeff Tantsura'; Keyur Patel (keyupate);= 'Jakob Heitz'; 'Thomas

> Mangin'; idr-bounces@ietf= .org

> Cc: idr@ietf.org<= /o:p>

> Subject: Re: [Idr] WG LC for draft-ietf-idr-= bgp-enhanced-route-refresh

>

> Any other comments?  (support/discussio= n accepted)

>

> Sue Hares

>

> PS - Keyur - spin a draft with this change a= nd end it to me.

>

> -----Original Message-----

> From: Idr [mailto:idr-bou= nces@ietf.org] On Behalf Of Jeff Tantsura

> Sent: Tuesday, January 28, 2014 5:56 PM=

> To: Keyur Patel (keyupate); Jakob Heitz; Tho= mas Mangin;

> idr-bounces@ietf.org

> Cc: idr@ietf.org<= /o:p>

> Subject: Re: [Idr] WG LC for draft-ietf-idr-= bgp-enhanced-route-refresh

>

> I support the wording below.

>

> Cheers,

> Jeff

>

>

> -----Original Message-----

> From: "keyupate@cisco.= com" <keyupate@cisco.com>= ;

> Date: Tuesday, January 28, 2014 1:43 PM=

> To: "keyupate@cisco.co= m" <keyupate@cisco.com>, Jakob Heitz <jakob.heitz@ericsson.com= >, Thomas Mangin <thomas.mangin@exa-ne= tworks.co.uk>, "idr-bounces@ietf.org"<= /p>

> <= idr-bounces@ietf.org<= /span>>

> Cc: "idr@ietf.org= " <idr@ietf.org>

> Subject: Re: [Idr] WG LC for draft-ietf-idr-= bgp-enhanced-route-refresh

>

>> Hi Jakob,

>>

>> How about the following (based on your s= uggestion):

>>

>> For a BGP speaker that supports the BGP = Graceful Restart specified in

>> [RFC4724] , it MUST NOT send a BoRR for = an AFI/SAFI to a neighbor

>> before it sends the EOR for the AFI/SAFI= to the neighbor.  This

>> procedure would help the neighbor avoid = the premature cleanup of

>> stale routes.

>>

>>

>> This would help simplify receiver side i= mplementation wrt GR and

>> Enhanced RR. :)

>>

>> Regards,

>> Keyur

>>

>>> On 1/28/14 1:08 PM, "Keyur Pate= l (keyupate)" <keyupate@cisco.com> w= rote:

>>>

>>> Sure! I am saying you can simplify t= he implementation by simply

>>> delaying the servicing of the route = refresh reply till the

>>> generation of

> an EOR.

>>>

>>> Question is do we allow the text to = be flexible enough to cover the

>>> other case. :)

>>>

>>> Regards,

>>> Keyur

>>>

>>>> On 1/28/14 12:56 PM, "Jakob= Heitz" <jakob.heitz@ericsson.com= > wrote:

>>>>

>>>> Could we please simplify this a = bit, not to force implementations

>>>> to use different stale bits?

>>>>

>>>> Thanks,

>>>> Jakob.

>>>>

>>>> -----Original Message-----<= /o:p>

>>>> From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com]

>>>> Sent: Tuesday, January 28, 2014 = 12:49 PM

>>>> To: Jakob Heitz; Thomas Mangin; = idr-bounces@ietf.org<= /span>

>>>> Cc: idr@ietf.org

>>>> Subject: Re: [Idr] WG LC for

>>>> draft-ietf-idr-bgp-enhanced-rout= e-refresh

>>>>

>>>>

>>>>

>>>>> On 1/28/14 12:23 PM, "J= akob Heitz" <jakob.heitz@ericsson.com= > wrote:

>>>>>

>>>>> the order BoRR, EoR, EoRR al= lows this possible scenario:

>>>>>

>>>>> Suppose 2 routes exist :1.1.= 1.1/32, 2.2.2.2/32 The order could now be:

>>>>> . start session

>>>>> . send 1.1.1.1/32=

>>>>> . receive route refresh requ= est.

>>>>> . send BoRR

>>>>> . send 2.2.2.2/32=

>>>>> . send EoR

>>>>> . send 1.1.1.1/32=

>>>>> . send EoRR

>>>>>

>>>>> On receipt of EoR, the recei= ver could delete stales, deleting

>>>>> 1.1.1.1/32.

>>>>

>>>> Not if you use different flags/b= its to mark them stale?

>>>>

>>>> Implementations could choose to = always postpone the route refresh

>>>> reply and get the same behavior?=

>>>>

>>>> Regards,

>>>> Keyur

>>>>

>>>>>

>>>>> Thanks,

>>>>> Jakob.

>>>>>

>>>>> -----Original Message-----

>>>>> From: Keyur Patel (keyupate)= [mailto:keyupate@cisco.com]

>>>>> Sent: Tuesday, January 28, 2= 014 12:17 PM

>>>>> To: Jakob Heitz; Thomas Mang= in; idr-bounces@ietf.org<= /span>

>>>>> Cc: idr@ietf.org<= /span>

>>>>> Subject: Re: [Idr] WG LC for=

>>>>> draft-ietf-idr-bgp-enhanced-= route-refresh

>>>>>

>>>>> The order: BoRR, EoR, EoRR l= ets an implementation do both,  merge

>>>>> route refresh reply with an = initial table announcement or delay

>>>>> the route refresh replies. A= s long as EoR is sent before EoRR

>>>>> there should be no issue rig= ht?

>>>>>

>>>>> Regards,

>>>>> Keyur

>>>>>> On 1/28/14 12:06 PM, &qu= ot;Jakob Heitz" <jakob.heitz@ericsson.com> wrote:

>>>>>>

>>>>>> Enke's text allows the o= rder: BoRR, EoR, EoRR.

>>>>>>

>>>>>> Could we change Enke's t= ext from

>>>>>> "it MUST NOT send a= n EoRR" to

>>>>>> "it MUST NOT send a= n BoRR"

>>>>>>

>>>>>> Thanks,

>>>>>> Jakob.

>>>>>>

>>>>>> -----Original Message---= --

>>>>>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Keyur Patel=

>>>>>> (keyupate)

>>>>>> Sent: Tuesday, January 2= 8, 2014 11:51 AM

>>>>>> To: Thomas Mangin; idr-bounces@ietf.org<= /span>

>>>>>> Cc: idr@ietf.= org

>>>>>> Subject: Re: [Idr] WG LC= for

>>>>>> draft-ietf-idr-bgp-enhan= ced-route-refresh

>>>>>>

>>>>>> Hi Jacob, Thomas,

>>>>>>

>>>>>> Am ok with implementatio= ns delaying the servicing of route

>>>>>> refresh request. Enke's = suggested text addresses the concern.

>>>>>>

>>>>>> Best Regards,=

>>>>>> Keyur

>>>>>>

>>>>>> On 1/26/14 3:39 PM, &quo= t;Thomas Mangin"

>>>>>> <thomas.mangin@exa-networks.co.uk>

>>>>>> wrote:

>>>>>>

>>>>>>> Damn, time to practi= ce then :)

>>>>>>>

>>>>>>> Joke apart, I agree = with this post. The feature should not be

>>>>>>> used ( and ignored )= until the initial route exchange has been completed.

>>>>>>>

>>>>>>> If the session drops= , I would expect the router to cancel any RR

>>>>>>> which was ongoing as= the AdjRIBOut is going to be retransmitted

>>>>>>> anyway.

>>>>>>>

>>>>>>> Thomas

>>>>>>>

>>>>>>> Sent from my iPad

>>>>>>>

>>>>>>>> On 25 Jan 2014, = at 19:48, Jakob Heitz

>>>>>>>> <jakob.heitz@ericsson.com>

>>>>>>>> wrote:

>>>>>>>>

>>>>>>>> RFCs are written= for coders "practiced" in the art".

>>>>>>>> If anyone sends = an EoRR before the adj-RIB-out is fully

>>>>>>>> populated, then = it's a BUG.

>>>>>>>> This does not ne= ed to be said.

>>>>>>>>

>>>>>>>> Personally, I be= lieve a route refresh request should not be

>>>>>>>> honored until GR= is complete.

>>>>>>>> Also, I don't be= lieve a timer for the receipt of EoRR is

>>>>>>>> necessary, becau= se the EoRR is guaranteed.

>>>>>>>> Guaranteed means= "unless the session drops first".

>>>>>>>> --

>>>>>>>>

>>>>>>>> Jakob Heitz.

>>>>>>>>

>>>>>>>> ________________= ________________________

>>>>>>>> From: Chris Hall= [chris.hall@highwayman.com]

>>>>>>>> Sent: Saturday, = 25 January 2014 11:27 AM

>>>>>>>> To: i= dr@ietf.org

>>>>>>>> Cc: Jakob Heitz<= o:p>

>>>>>>>> Subject: RE: [Id= r] WG LC for

>>>>>>>> draft-ietf-idr-b= gp-enhanced-route-refresh

>>>>>>>>

>>>>>>>> Jakob Heitz wrot= e (on Fri 24-Jan-2014 at 20:37):

>>>>>>>> ...

>>>>>>>>> Silence mean= s don't do it.

>>>>>>>>

>>>>>>>> Hmmm.... as a pr= inciple I'm more comfortable with "that which

>>>>>>>> isn't prohibited= is permitted"....

>>>>>>>>

>>>>>>>>> You would de= finitely NOT want BoRR to flush old stales.

>>>>>>>>

>>>>>>>> ....but, given t= he definite requirement, and given that the

>>>>>>>> current preceden= t for "marking stale" does flush old stale,

>>>>>>>> then a few words= for the avoidance of doubt ?

>>>>>>>>

>>>>>>>>> Restarting t= he timer might be a good idea.

>>>>>>>>

>>>>>>>> I dunno... a rou= te which remains stale for "a long time" is, of

>>>>>>>> course, a candid= ate for being withdrawn: so having started a

>>>>>>>> timer the first = time things are set stale, I would avoid

>>>>>>>> extending that

>>>>>>>> -- at least for = Graceful Restart, where the whole withdraw

>>>>>>>> thing has been &= quot;on-hold" since the last session failed.  For

>>>>>>>> route-refresh I = guess there's more of a presumption that stale

>>>>>>>> routes will be r= efreshed sooner or later, and in the meantime

>>>>>>>> they remain good= .  So if the route-refresh is (repeatedly)

>>>>>>>> restarted for so= me reason, perhaps it is more reasonable to

>>>>>>>> extend the flush= deadline -- but avoid doing this indefinitely ?

>>>>>>>>

>>>>>>>> FWIW, for route-= refresh and for GR, the Adj-RIB-Out mechanics I

>>>>>>>> have built in Qu= agga prioritise route changes (pending changes

>>>>>>>> and any that occ= ur during the refresh) over refresh updates.

>>>>>>>> This makes it mo= re likely that remaining stale routes are still

> good.

>>>>>>>> But the other en= d cannot know that.

>>>>>>>>

>>>>>>>> The paragraph in= the draft discussing the "entire Adj-RIB-Out"

>>>>>>>> defines that to = be the entries present "at the start of the

>>>>>>>> route refresh op= eration", and observes that these comprise both

>>>>>>>> reachable and un= reachable routes.  [An "of" after "comprise"

>>>>>>>> sets teeth on ed= ge, BTW.]  I'm really not sure what this

>>>>>>>> paragraph is try= ing to tell me.

>>>>>>>> The reference to= unreachable routes appears to suggest that

>>>>>>>> pending withdraw= s should be sent as part of the refresh -- so

>>>>>>>> not left to the = EoRR to implement at the end.  The point at

>>>>>>>> which the EoRR i= s sent is defined such that it excludes any

>>>>>>>> Adj-RIB-Out entr= ies added after the route-refresh started, but

>>>>>>>> includes any whi= ch are changed during the process.  It seems

>>>>>>>> reasonable to de= lay any brand new reachable prefixes until

>>>>>>>> after all previo= usly announced ones have been refreshed and the

>>>>>>>> EoRR sent -- if = that's the

> intent here.

>>>>>>>> Changes which oc= cur before the refresh gets to a given entry

>>>>>>>> are pretty natur= ally swept up by the refresh.  Changes which

>>>>>>>> occur after the = refresh has gone past, could/should be deferred

>>>>>>>> to after the EoR= R ?

>>>>>>>> Does it make a d= ifference if the change is a withdraw ?  (Of

>>>>>>>> course MRAI may = kick in here.  Ah.  MRAI and route-refresh,

>>>>>>>> there's a topic<= o:p>

>>>>>>>> !)

>>>>>>>>

>>>>>>>> I think the esse= nce of the rule is that the EoRR should be sent

>>>>>>>> once  all p= refixes previously advertised to the peer as

>>>>>>>> reachable have&n= bsp; been refreshed, ie announced or withdrawn (at least) once.<= /p>

>>>>>>>> Or,  perhap= s more strictly, not *before* those prefixes have

>>>>>>>> *all* been = announced once -- given that the EoRR will promptly

>>>>>>>> bang un-advertis= ed stuff on the head.  Even more strictly

>>>>>>>> perhaps: not sen= d EoRR *before* any withdraws implied by it are

>>>>>>>> required or desi= rable.

>>>>>>>>

>>>>>>>> Depending on the= implementation, a given sender may or may not

>>>>>>>> be able to deter= mine the minimum set of updates required before

>>>>>>>> sending EoRR.

>>>>>>>>

>>>>>>>> If the refresh o= peration takes a long time, there may be good

>>>>>>>> routeing reasons= to arrange for some route changes to be sent

>>>>>>>> to the peer &quo= t;early" -- that is to send announcements which do

>>>>>>>> not contribute t= o the refresh, but which are important enough

>>>>>>>> to warrant delay= ing the end of the refresh.  That could be a

>>>>>>>> matter for<= /o:p>

>>>>>>>> recommendation(s= ) in the standard.

>>>>>>>>

>>>>>>>> NB: given that t= he timing of the EoRR is tied to the state of

>>>>>>>> the Adj-RIB-Out,= I'm not sure about the Graceful Restart

> assumptions.

>>>>>>>> At the beginning= of the initial update, the Restarting and

>>>>>>>> Receiving speake= rs have:

>>>>>>>>

>>>>>>>> Restarting: = ; Empty Adj-RIB-In   Empty Adj-RIB-Out

>>>>>>>>

>>>>>>>> Receiving: =   Empty Adj-RIB-Out  Stale Adj-RIB-In

>>>>>>>>

>>>>>>>> Now suppose (bon= kers or otherwise) the receiving speaker sends

>>>>>>>> an RRQ part way = through the initial update.  The restarting

>>>>>>>> speaker responds= with BoRR, everything in its Adj-RIB-Out, and

>>>>>>>> EoRR -- per spec= ification.  The receiving speaker sees the

>>>>>>>> EoRR, and flushe= s stale.  Unfortunately, if the restarting

>>>>>>>> speaker has not = yet fully populated its Adj-RIB-Out, then many

>>>>>>>> further routes w= ill be sent before the EoR falls due -- but the

>>>>>>>> receiving speake= r has already flushed their tiny posteriors :-(

>>>>>>>>

>>>>>>>> I am coming to t= he view that route-refresh during a Graceful

>>>>>>>> Restart initial = update is a horse of a different colour altogether.

>>>>>>>>

>>>>>>>> [So the assumpti= on that EoRR and EoR are triggered by the same

>>>>>>>> thing was comple= tely wrong, and I apologise for it.]

>>>>>>>>

>>>>>>>> Chris=

>>>>>>>>

>>>>>>>> ________________= _______________________________

>>>>>>>> Idr mailing list=

>>>>>>>> Idr@i= etf.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<= /span>

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

>>>

>>> ____________________________________= ___________

>>> Idr mailing list

>>> Idr@ietf.org

>>> htt= ps://www.ietf.org/mailman/listinfo/idr

>>

>> ________________________________________= _______

>> Idr mailing list

>> Idr@ietf.org<= /o:p>

>> 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_8ED5B0B0F5B4854A912480C1521F973A11AFCCA6xmbrcdx13ciscoc_-- From jakob.heitz@ericsson.com Wed Jan 29 17:52:58 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C87731A03EA; Wed, 29 Jan 2014 17:52:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6S9QW5ihFSj; Wed, 29 Jan 2014 17:52:51 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 50C771A0251; Wed, 29 Jan 2014 17:52:51 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-8d-52e9b070ddff Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 84.7D.11484.070B9E25; Thu, 30 Jan 2014 02:52:48 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0387.000; Wed, 29 Jan 2014 20:52:47 -0500 From: Jakob Heitz To: "Saikat Ray (sairay)" , Thomas Mangin Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPF5KdKHMolEg8TF26AxOKep0T6JqRMOhAgAGfMAD//7gu+4AAX1gA//+1BTCAAHhgAP//sQGgAA5+ToAABygAoAAmsOcAAAoIr7AAJlf4AP//r6/0gAIo+ACAAuS2AIAAU2KQ//+z84CAAFNj0P//taAAgABTAKD//7JCgAABOPmAAA4zvAAAB5PVAAAOxxsAAA9Xy4AABpuWgAAKQktg Date: Thu, 30 Jan 2014 01:52:46 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F7116F@eusaamb109.ericsson.se> References: <010801cf1c8c$6b1a0420$414e0c60$@ndzh.com> <8ED5B0B0F5B4854A912480C1521F973A11AFBD56@xmb-rcd-x13.cisco.com> <6D84FB20-2A48-4830-92F5-C81C5F4AA36A@exa-networks.co.uk> <8ED5B0B0F5B4854A912480C1521F973A11AFCCA6@xmb-rcd-x13.cisco.com> In-Reply-To: <8ED5B0B0F5B4854A912480C1521F973A11AFCCA6@xmb-rcd-x13.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_2F3EBB88EC3A454AAB08915FBF0B8C7E02F7116Feusaamb109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZXLonULdgw8sgg0X7DC3mbJzOavHq9jMm i8at59ks9hxazmbx580rFotJ21azOrB5TPm9kdWj/+xmJo8lS34yecx+fZ01gCWKyyYlNSez LLVI3y6BK2P/fveCZ+0sFS/P6DYw3j/O3MXIySEhYCJx8PBlRghbTOLCvfVsXYxcHEICRxgl fjVdAksICSxnlNg+qR7EZhPQkfh2vQusWUQgQaJh30k2EJtZ4ByjxOVXGiC2sICbxN2Wz0wQ Ne4SLT8mMYMMFRF4xijx9N1/sASLgKrEjVVLwJp5BXwlpszZxQ6x+QyTxLar18A2cwIl7m/9 AmYzAp33/dQaJoht4hK3nsxngjhbQGLJnvNQ74hKvHz8jxXCVpKYtPQcK0R9vsSD/UdZIJYJ Spyc+YRlAqPoLCSjZiEpm4WkDCKuI7Fg9yc2CFtbYtnC18ww9pkDj5mQxRcwsq9i5CgtTi3L TTcy3MQIjMpjEmyOOxgXfLI8xCjNwaIkzvvlrXOQkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6p BkamlHcxDE/sWRVcF3DIqnzOviirJpB/VP31yp/TrOeeiuh+v5Cjpfaq0WS7XwKh8xt2Fe5Y zrKjltlpaf8ny4VaHKa7DA7erH7Ns2iftc8WA+7LX0Le/FPa1q0d231fI3/x1rZ2g5b0v4zL I56WzuldI/KioPvY00XTTA9pyasICMeLFVf/+KLEUpyRaKjFXFScCADDUl53mAIAAA== Cc: "Keyur Patel \(keyupate\)" , "idr@ietf.org" , Susan Hares , "idr-bounces@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 01:52:59 -0000 --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E02F7116Feusaamb109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes Saikat, but... The intent is to verify the routing table that was supposed to have been bu= ilt with proper update messages. If an EoRR deletes an unexpected stale route, it should be logged and debug= ged. Notwithstanding routes deleted by policy changes. For example, we should not invent a mass withdraw procedure like sending Bo= RR followed directly by EoRR without any intervening update messages. I can see a few people gagging now :) Thanks, Jakob. From: Saikat Ray (sairay) [mailto:sairay@cisco.com] Sent: Wednesday, January 29, 2014 5:38 PM To: Thomas Mangin Cc: Susan Hares; Jeff Tantsura; Keyur Patel (keyupate); Jakob Heitz; idr-bo= unces@ietf.org; idr@ietf.org Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh The route may have been advertised before (and not (yet) withdrawn). Consid= er the example: +---+ +---+ | A +-----+ B | +---+ +---+ t=3D0: A sends three prefixes: 1.1.1.1/32, 2.2.2.2/32, 3.3.3.3/32, to B. t=3D1: B sends an (enhanced) route-refresh request to A. t=3D2: A sends BoRR to B. t=3D3: A sends 1.1.1.1/32 and 2.2.2.2/32 to B t=3D4: A sends EoRR to B. At this point, both A and B MUST treat 3.3.3.3/32 as withdrawn even though = there was no explicit withdraw sent for it. That means, A doesn't need to s= end an explicit withdraw for 3.3.3.3/32, and B must delete 3.3.3.3/32's pat= h from A. This is the core semantics of BoRR and EoRR and it takes care of all cases.= This implies, e.g., if the sender A want to ensure that a particular prefi= x, x.y.z.w/n, is not considered withdrawn by the receiver, then A MUST adve= rtise x.y.z.w/n following any BoRR (even in nested cases) *before* any EoRR= . -----Original Message----- From: Thomas Mangin [mailto:thomas.mangin@exa-networks.co.uk] Sent: Tuesday, January 28, 2014 11:50 PM To: Saikat Ray (sairay) Cc: Susan Hares; Jeff Tantsura; Keyur Patel (keyupate); Jakob Heitz; idr-bo= unces@ietf.org; idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hello Saikat, Why "both by the sender", if the route was not announced it is clearly with= drawn on the sender side and by definition if a route is not in the RR it h= as to be withdrawn - that said saying it can not harm .. Thomas Sent from my iPad > On 29 Jan 2014, at 01:03, "Saikat Ray \(sairay\)" > wrote: > > The draft should add a line mandating the actual semantics (instead of/in= addition to the procedures of mark-and-sweep). Something along the line: > > "Any route for which no update has been sent between a BoRR and the follo= wing EoRR MUST be considered withdrawn by both the sender and the receiver.= " > > The rest is really implementation (how to handle nested BoRR/EoRR or GR E= oR, etc.), IMHO. > > I support the draft, BTW. > > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares > Sent: Tuesday, January 28, 2014 4:53 PM > To: 'Jeff Tantsura'; Keyur Patel (keyupate); 'Jakob Heitz'; 'Thomas > Mangin'; idr-bounces@ietf.org > Cc: idr@ietf.org > Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh > > Any other comments? (support/discussion accepted) > > Sue Hares > > PS - Keyur - spin a draft with this change and end it to me. > > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jeff Tantsura > Sent: Tuesday, January 28, 2014 5:56 PM > To: Keyur Patel (keyupate); Jakob Heitz; Thomas Mangin; > idr-bounces@ietf.org > Cc: idr@ietf.org > Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh > > I support the wording below. > > Cheers, > Jeff > > > -----Original Message----- > From: "keyupate@cisco.com" > > Date: Tuesday, January 28, 2014 1:43 PM > To: "keyupate@cisco.com" >, Jakob Heitz >, Thomas Mangin >, "idr-bounces@ietf.org" > > > Cc: "idr@ietf.org" > > Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh > >> Hi Jakob, >> >> How about the following (based on your suggestion): >> >> For a BGP speaker that supports the BGP Graceful Restart specified in >> [RFC4724] , it MUST NOT send a BoRR for an AFI/SAFI to a neighbor >> before it sends the EOR for the AFI/SAFI to the neighbor. This >> procedure would help the neighbor avoid the premature cleanup of >> stale routes. >> >> >> This would help simplify receiver side implementation wrt GR and >> Enhanced RR. :) >> >> Regards, >> Keyur >> >>> On 1/28/14 1:08 PM, "Keyur Patel (keyupate)" > wrote: >>> >>> Sure! I am saying you can simplify the implementation by simply >>> delaying the servicing of the route refresh reply till the >>> generation of > an EOR. >>> >>> Question is do we allow the text to be flexible enough to cover the >>> other case. :) >>> >>> Regards, >>> Keyur >>> >>>> On 1/28/14 12:56 PM, "Jakob Heitz" > wrote: >>>> >>>> Could we please simplify this a bit, not to force implementations >>>> to use different stale bits? >>>> >>>> Thanks, >>>> Jakob. >>>> >>>> -----Original Message----- >>>> From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] >>>> Sent: Tuesday, January 28, 2014 12:49 PM >>>> To: Jakob Heitz; Thomas Mangin; idr-bounces@ietf.org >>>> Cc: idr@ietf.org >>>> Subject: Re: [Idr] WG LC for >>>> draft-ietf-idr-bgp-enhanced-route-refresh >>>> >>>> >>>> >>>>> On 1/28/14 12:23 PM, "Jakob Heitz" > wrote: >>>>> >>>>> the order BoRR, EoR, EoRR allows this possible scenario: >>>>> >>>>> Suppose 2 routes exist :1.1.1.1/32, 2.2.2.2/32 The order could now be= : >>>>> . start session >>>>> . send 1.1.1.1/32 >>>>> . receive route refresh request. >>>>> . send BoRR >>>>> . send 2.2.2.2/32 >>>>> . send EoR >>>>> . send 1.1.1.1/32 >>>>> . send EoRR >>>>> >>>>> On receipt of EoR, the receiver could delete stales, deleting >>>>> 1.1.1.1/32. >>>> >>>> Not if you use different flags/bits to mark them stale? >>>> >>>> Implementations could choose to always postpone the route refresh >>>> reply and get the same behavior? >>>> >>>> Regards, >>>> Keyur >>>> >>>>> >>>>> Thanks, >>>>> Jakob. >>>>> >>>>> -----Original Message----- >>>>> From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] >>>>> Sent: Tuesday, January 28, 2014 12:17 PM >>>>> To: Jakob Heitz; Thomas Mangin; idr-bounces@ietf.org >>>>> Cc: idr@ietf.org >>>>> Subject: Re: [Idr] WG LC for >>>>> draft-ietf-idr-bgp-enhanced-route-refresh >>>>> >>>>> The order: BoRR, EoR, EoRR lets an implementation do both, merge >>>>> route refresh reply with an initial table announcement or delay >>>>> the route refresh replies. As long as EoR is sent before EoRR >>>>> there should be no issue right? >>>>> >>>>> Regards, >>>>> Keyur >>>>>> On 1/28/14 12:06 PM, "Jakob Heitz" > wrote: >>>>>> >>>>>> Enke's text allows the order: BoRR, EoR, EoRR. >>>>>> >>>>>> Could we change Enke's text from >>>>>> "it MUST NOT send an EoRR" to >>>>>> "it MUST NOT send an BoRR" >>>>>> >>>>>> Thanks, >>>>>> Jakob. >>>>>> >>>>>> -----Original Message----- >>>>>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Keyur Patel >>>>>> (keyupate) >>>>>> Sent: Tuesday, January 28, 2014 11:51 AM >>>>>> To: Thomas Mangin; idr-bounces@ietf.org >>>>>> Cc: idr@ietf.org >>>>>> Subject: Re: [Idr] WG LC for >>>>>> draft-ietf-idr-bgp-enhanced-route-refresh >>>>>> >>>>>> Hi Jacob, Thomas, >>>>>> >>>>>> Am ok with implementations delaying the servicing of route >>>>>> refresh request. Enke's suggested text addresses the concern. >>>>>> >>>>>> Best Regards, >>>>>> Keyur >>>>>> >>>>>> On 1/26/14 3:39 PM, "Thomas Mangin" >>>>>> > >>>>>> wrote: >>>>>> >>>>>>> Damn, time to practice then :) >>>>>>> >>>>>>> Joke apart, I agree with this post. The feature should not be >>>>>>> used ( and ignored ) until the initial route exchange has been comp= leted. >>>>>>> >>>>>>> If the session drops, I would expect the router to cancel any RR >>>>>>> which was ongoing as the AdjRIBOut is going to be retransmitted >>>>>>> anyway. >>>>>>> >>>>>>> Thomas >>>>>>> >>>>>>> Sent from my iPad >>>>>>> >>>>>>>> On 25 Jan 2014, at 19:48, Jakob Heitz >>>>>>>> > >>>>>>>> wrote: >>>>>>>> >>>>>>>> RFCs are written for coders "practiced" in the art". >>>>>>>> If anyone sends an EoRR before the adj-RIB-out is fully >>>>>>>> populated, then it's a BUG. >>>>>>>> This does not need to be said. >>>>>>>> >>>>>>>> Personally, I believe a route refresh request should not be >>>>>>>> honored until GR is complete. >>>>>>>> Also, I don't believe a timer for the receipt of EoRR is >>>>>>>> necessary, because the EoRR is guaranteed. >>>>>>>> Guaranteed means "unless the session drops first". >>>>>>>> -- >>>>>>>> >>>>>>>> Jakob Heitz. >>>>>>>> >>>>>>>> ________________________________________ >>>>>>>> From: Chris Hall [chris.hall@highwayman.com] >>>>>>>> Sent: Saturday, 25 January 2014 11:27 AM >>>>>>>> To: idr@ietf.org >>>>>>>> Cc: Jakob Heitz >>>>>>>> Subject: RE: [Idr] WG LC for >>>>>>>> draft-ietf-idr-bgp-enhanced-route-refresh >>>>>>>> >>>>>>>> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): >>>>>>>> ... >>>>>>>>> Silence means don't do it. >>>>>>>> >>>>>>>> Hmmm.... as a principle I'm more comfortable with "that which >>>>>>>> isn't prohibited is permitted".... >>>>>>>> >>>>>>>>> You would definitely NOT want BoRR to flush old stales. >>>>>>>> >>>>>>>> ....but, given the definite requirement, and given that the >>>>>>>> current precedent for "marking stale" does flush old stale, >>>>>>>> then a few words for the avoidance of doubt ? >>>>>>>> >>>>>>>>> Restarting the timer might be a good idea. >>>>>>>> >>>>>>>> I dunno... a route which remains stale for "a long time" is, of >>>>>>>> course, a candidate for being withdrawn: so having started a >>>>>>>> timer the first time things are set stale, I would avoid >>>>>>>> extending that >>>>>>>> -- at least for Graceful Restart, where the whole withdraw >>>>>>>> thing has been "on-hold" since the last session failed. For >>>>>>>> route-refresh I guess there's more of a presumption that stale >>>>>>>> routes will be refreshed sooner or later, and in the meantime >>>>>>>> they remain good. So if the route-refresh is (repeatedly) >>>>>>>> restarted for some reason, perhaps it is more reasonable to >>>>>>>> extend the flush deadline -- but avoid doing this indefinitely ? >>>>>>>> >>>>>>>> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I >>>>>>>> have built in Quagga prioritise route changes (pending changes >>>>>>>> and any that occur during the refresh) over refresh updates. >>>>>>>> This makes it more likely that remaining stale routes are still > good. >>>>>>>> But the other end cannot know that. >>>>>>>> >>>>>>>> The paragraph in the draft discussing the "entire Adj-RIB-Out" >>>>>>>> defines that to be the entries present "at the start of the >>>>>>>> route refresh operation", and observes that these comprise both >>>>>>>> reachable and unreachable routes. [An "of" after "comprise" >>>>>>>> sets teeth on edge, BTW.] I'm really not sure what this >>>>>>>> paragraph is trying to tell me. >>>>>>>> The reference to unreachable routes appears to suggest that >>>>>>>> pending withdraws should be sent as part of the refresh -- so >>>>>>>> not left to the EoRR to implement at the end. The point at >>>>>>>> which the EoRR is sent is defined such that it excludes any >>>>>>>> Adj-RIB-Out entries added after the route-refresh started, but >>>>>>>> includes any which are changed during the process. It seems >>>>>>>> reasonable to delay any brand new reachable prefixes until >>>>>>>> after all previously announced ones have been refreshed and the >>>>>>>> EoRR sent -- if that's the > intent here. >>>>>>>> Changes which occur before the refresh gets to a given entry >>>>>>>> are pretty naturally swept up by the refresh. Changes which >>>>>>>> occur after the refresh has gone past, could/should be deferred >>>>>>>> to after the EoRR ? >>>>>>>> Does it make a difference if the change is a withdraw ? (Of >>>>>>>> course MRAI may kick in here. Ah. MRAI and route-refresh, >>>>>>>> there's a topic >>>>>>>> !) >>>>>>>> >>>>>>>> I think the essence of the rule is that the EoRR should be sent >>>>>>>> once all prefixes previously advertised to the peer as >>>>>>>> reachable have been refreshed, ie announced or withdrawn (at leas= t) once. >>>>>>>> Or, perhaps more strictly, not *before* those prefixes have >>>>>>>> *all* been announced once -- given that the EoRR will promptly >>>>>>>> bang un-advertised stuff on the head. Even more strictly >>>>>>>> perhaps: not send EoRR *before* any withdraws implied by it are >>>>>>>> required or desirable. >>>>>>>> >>>>>>>> Depending on the implementation, a given sender may or may not >>>>>>>> be able to determine the minimum set of updates required before >>>>>>>> sending EoRR. >>>>>>>> >>>>>>>> If the refresh operation takes a long time, there may be good >>>>>>>> routeing reasons to arrange for some route changes to be sent >>>>>>>> to the peer "early" -- that is to send announcements which do >>>>>>>> not contribute to the refresh, but which are important enough >>>>>>>> to warrant delaying the end of the refresh. That could be a >>>>>>>> matter for >>>>>>>> recommendation(s) in the standard. >>>>>>>> >>>>>>>> NB: given that the timing of the EoRR is tied to the state of >>>>>>>> the Adj-RIB-Out, I'm not sure about the Graceful Restart > assumptions. >>>>>>>> At the beginning of the initial update, the Restarting and >>>>>>>> Receiving speakers have: >>>>>>>> >>>>>>>> Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out >>>>>>>> >>>>>>>> Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In >>>>>>>> >>>>>>>> Now suppose (bonkers or otherwise) the receiving speaker sends >>>>>>>> an RRQ part way through the initial update. The restarting >>>>>>>> speaker responds with BoRR, everything in its Adj-RIB-Out, and >>>>>>>> EoRR -- per specification. The receiving speaker sees the >>>>>>>> EoRR, and flushes stale. Unfortunately, if the restarting >>>>>>>> speaker has not yet fully populated its Adj-RIB-Out, then many >>>>>>>> further routes will be sent before the EoR falls due -- but the >>>>>>>> receiving speaker has already flushed their tiny posteriors :-( >>>>>>>> >>>>>>>> I am coming to the view that route-refresh during a Graceful >>>>>>>> Restart initial update is a horse of a different colour altogether= . >>>>>>>> >>>>>>>> [So the assumption that EoRR and EoR are triggered by the same >>>>>>>> thing was completely wrong, and I apologise for it.] >>>>>>>> >>>>>>>> Chris >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >> >> _______________________________________________ >> 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_2F3EBB88EC3A454AAB08915FBF0B8C7E02F7116Feusaamb109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes Saikat, but…=

 

The intent is to verif= y the routing table that was supposed to have been built with proper update= messages.

If an EoRR deletes an = unexpected stale route, it should be logged and debugged. Notwithstanding r= outes deleted by policy changes.

For example, we should= not invent a mass withdraw procedure like sending BoRR followed directly b= y EoRR without any intervening update messages.

I can see a few people= gagging now J

 

Thanks,

Jakob.

 

From: Saikat R= ay (sairay) [mailto:sairay@cisco.com]
Sent: Wednesday, January 29, 2014 5:38 PM
To: Thomas Mangin
Cc: Susan Hares; Jeff Tantsura; Keyur Patel (keyupate); Jakob Heitz;= idr-bounces@ietf.org; idr@ietf.org
Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refre= sh

 

The route may have been advertised before (and no= t (yet) withdrawn). Consider the example:

 

+---+     +---+

| A +-----+ B |

+---+     +---+

 

t=3D0: A sends three prefixes: 1.1.1.1/32, 2.2.2.= 2/32, 3.3.3.3/32, to B.

t=3D1: B sends an (enhanced) route-refresh reques= t to A.

t=3D2: A sends BoRR to B.

t=3D3: A sends 1.1.1.1/32 and 2.2.2.2/32 to B

t=3D4: A sends EoRR to B.

 

At this point, both A and B MUST treat 3.3.3.3/32= as withdrawn even though there was no explicit withdraw sent for it. That = means, A doesn’t need to send an explicit withdraw for 3.3.3.3/32, an= d B must delete 3.3.3.3/32’s path from A.

 

This is the core semantics of BoRR and EoRR and i= t takes care of all cases. This implies, e.g., if the sender A want to ensu= re that a particular prefix, x.y.z.w/n, is not considered withdrawn by the = receiver, then A MUST advertise x.y.z.w/n following any BoRR (even in nested cases) *before* any EoRR.

 

-----Original Message-----
From: Thomas Mangin [ma= ilto:thomas.mangin@exa-networks.co.uk]
Sent: Tuesday, January 28, 2014 11:50 PM
To: Saikat Ray (sairay)
Cc: Susan Hares; Jeff Tantsura; Keyur Patel (keyupate); Jakob Heitz; idr-bounces@ietf.org; idr@ietf.org<= br> Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh=

 

Hello Saikat,

 

Why "both by the sender", if the route = was not announced it is clearly withdrawn on the sender side and by definit= ion if a route is not in the RR it has to be withdrawn - that said saying i= t can not harm ..

 

Thomas

 

Sent from my iPad

 

> On 29 Jan 2014, at 01:03, "Saikat Ray \= (sairay\)" <sairay@cisco.com> wrote:

>

> The draft should add a line mandating the ac= tual semantics (instead of/in addition to the procedures of mark-and-sweep)= . Something along the line:

>

> "Any route for which no update has been= sent between a BoRR and the following EoRR MUST be considered withdrawn by= both the sender and the receiver."

>

> The rest is really implementation (how to ha= ndle nested BoRR/EoRR or GR EoR, etc.), IMHO.

>

> I support the draft, BTW.

>

> -----Original Message-----

> From: Idr [mailto:idr-bou= nces@ietf.org] On Behalf Of Susan Hares

> Sent: Tuesday, January 28, 2014 4:53 PM=

> To: 'Jeff Tantsura'; Keyur Patel (keyupate);= 'Jakob Heitz'; 'Thomas

> Mangin'; idr-bounces@ietf= .org

> Cc: idr@ietf.org<= /o:p>

> Subject: Re: [Idr] WG LC for draft-ietf-idr-= bgp-enhanced-route-refresh

>

> Any other comments?  (support/discussio= n accepted)

>

> Sue Hares

>

> PS - Keyur - spin a draft with this change a= nd end it to me.

>

> -----Original Message-----

> From: Idr [mailto:idr-bou= nces@ietf.org] On Behalf Of Jeff Tantsura

> Sent: Tuesday, January 28, 2014 5:56 PM=

> To: Keyur Patel (keyupate); Jakob Heitz; Tho= mas Mangin;

> idr-bounces@ietf.org

> Cc: idr@ietf.org<= /o:p>

> Subject: Re: [Idr] WG LC for draft-ietf-idr-= bgp-enhanced-route-refresh

>

> I support the wording below.

>

> Cheers,

> Jeff

>

>

> -----Original Message-----

> From: "keyupate@cisco.= com" <keyupate@cisco.com>= ;

> Date: Tuesday, January 28, 2014 1:43 PM=

> To: "keyupate@cisco.co= m" <keyupate@cisco.com>, Jakob Heitz <jakob.heitz@ericsson.com= >, Thomas Mangin <thomas.mangin@exa-ne= tworks.co.uk>, "idr-bounces@ietf.org"<= /p>

> <= idr-bounces@ietf.org<= /span>>

> Cc: "idr@ietf.org= " <idr@ietf.org>

> Subject: Re: [Idr] WG LC for draft-ietf-idr-= bgp-enhanced-route-refresh

>

>> Hi Jakob,

>>

>> How about the following (based on your s= uggestion):

>>

>> For a BGP speaker that supports the BGP = Graceful Restart specified in

>> [RFC4724] , it MUST NOT send a BoRR for = an AFI/SAFI to a neighbor

>> before it sends the EOR for the AFI/SAFI= to the neighbor.  This

>> procedure would help the neighbor avoid = the premature cleanup of

>> stale routes.

>>

>>

>> This would help simplify receiver side i= mplementation wrt GR and

>> Enhanced RR. :)

>>

>> Regards,

>> Keyur

>>

>>> On 1/28/14 1:08 PM, "Keyur Pate= l (keyupate)" <keyupate@cisco.com> w= rote:

>>>

>>> Sure! I am saying you can simplify t= he implementation by simply

>>> delaying the servicing of the route = refresh reply till the

>>> generation of

> an EOR.

>>>

>>> Question is do we allow the text to = be flexible enough to cover the

>>> other case. :)

>>>

>>> Regards,

>>> Keyur

>>>

>>>> On 1/28/14 12:56 PM, "Jakob= Heitz" <jakob.heitz@ericsson.com= > wrote:

>>>>

>>>> Could we please simplify this a = bit, not to force implementations

>>>> to use different stale bits?

>>>>

>>>> Thanks,

>>>> Jakob.

>>>>

>>>> -----Original Message-----<= /o:p>

>>>> From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com]

>>>> Sent: Tuesday, January 28, 2014 = 12:49 PM

>>>> To: Jakob Heitz; Thomas Mangin; = idr-bounces@ietf.org<= /span>

>>>> Cc: idr@ietf.org

>>>> Subject: Re: [Idr] WG LC for

>>>> draft-ietf-idr-bgp-enhanced-rout= e-refresh

>>>>

>>>>

>>>>

>>>>> On 1/28/14 12:23 PM, "J= akob Heitz" <jakob.heitz@ericsson.com= > wrote:

>>>>>

>>>>> the order BoRR, EoR, EoRR al= lows this possible scenario:

>>>>>

>>>>> Suppose 2 routes exist :1.1.= 1.1/32, 2.2.2.2/32 The order could now be:

>>>>> . start session

>>>>> . send 1.1.1.1/32=

>>>>> . receive route refresh requ= est.

>>>>> . send BoRR

>>>>> . send 2.2.2.2/32=

>>>>> . send EoR

>>>>> . send 1.1.1.1/32=

>>>>> . send EoRR

>>>>>

>>>>> On receipt of EoR, the recei= ver could delete stales, deleting

>>>>> 1.1.1.1/32.

>>>>

>>>> Not if you use different flags/b= its to mark them stale?

>>>>

>>>> Implementations could choose to = always postpone the route refresh

>>>> reply and get the same behavior?=

>>>>

>>>> Regards,

>>>> Keyur

>>>>

>>>>>

>>>>> Thanks,

>>>>> Jakob.

>>>>>

>>>>> -----Original Message-----

>>>>> From: Keyur Patel (keyupate)= [mailto:keyupate@cisco.com]

>>>>> Sent: Tuesday, January 28, 2= 014 12:17 PM

>>>>> To: Jakob Heitz; Thomas Mang= in; idr-bounces@ietf.org<= /span>

>>>>> Cc: idr@ietf.org<= /span>

>>>>> Subject: Re: [Idr] WG LC for=

>>>>> draft-ietf-idr-bgp-enhanced-= route-refresh

>>>>>

>>>>> The order: BoRR, EoR, EoRR l= ets an implementation do both,  merge

>>>>> route refresh reply with an = initial table announcement or delay

>>>>> the route refresh replies. A= s long as EoR is sent before EoRR

>>>>> there should be no issue rig= ht?

>>>>>

>>>>> Regards,

>>>>> Keyur

>>>>>> On 1/28/14 12:06 PM, &qu= ot;Jakob Heitz" <jakob.heitz@ericsson.com> wrote:

>>>>>>

>>>>>> Enke's text allows the o= rder: BoRR, EoR, EoRR.

>>>>>>

>>>>>> Could we change Enke's t= ext from

>>>>>> "it MUST NOT send a= n EoRR" to

>>>>>> "it MUST NOT send a= n BoRR"

>>>>>>

>>>>>> Thanks,

>>>>>> Jakob.

>>>>>>

>>>>>> -----Original Message---= --

>>>>>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Keyur Patel=

>>>>>> (keyupate)

>>>>>> Sent: Tuesday, January 2= 8, 2014 11:51 AM

>>>>>> To: Thomas Mangin; idr-bounces@ietf.org<= /span>

>>>>>> Cc: idr@ietf.= org

>>>>>> Subject: Re: [Idr] WG LC= for

>>>>>> draft-ietf-idr-bgp-enhan= ced-route-refresh

>>>>>>

>>>>>> Hi Jacob, Thomas,

>>>>>>

>>>>>> Am ok with implementatio= ns delaying the servicing of route

>>>>>> refresh request. Enke's = suggested text addresses the concern.

>>>>>>

>>>>>> Best Regards,=

>>>>>> Keyur

>>>>>>

>>>>>> On 1/26/14 3:39 PM, &quo= t;Thomas Mangin"

>>>>>> <thomas.mangin@exa-networks.co.uk>

>>>>>> wrote:

>>>>>>

>>>>>>> Damn, time to practi= ce then :)

>>>>>>>

>>>>>>> Joke apart, I agree = with this post. The feature should not be

>>>>>>> used ( and ignored )= until the initial route exchange has been completed.

>>>>>>>

>>>>>>> If the session drops= , I would expect the router to cancel any RR

>>>>>>> which was ongoing as= the AdjRIBOut is going to be retransmitted

>>>>>>> anyway.

>>>>>>>

>>>>>>> Thomas

>>>>>>>

>>>>>>> Sent from my iPad

>>>>>>>

>>>>>>>> On 25 Jan 2014, = at 19:48, Jakob Heitz

>>>>>>>> <jakob.heitz@ericsson.com>

>>>>>>>> wrote:

>>>>>>>>

>>>>>>>> RFCs are written= for coders "practiced" in the art".

>>>>>>>> If anyone sends = an EoRR before the adj-RIB-out is fully

>>>>>>>> populated, then = it's a BUG.

>>>>>>>> This does not ne= ed to be said.

>>>>>>>>

>>>>>>>> Personally, I be= lieve a route refresh request should not be

>>>>>>>> honored until GR= is complete.

>>>>>>>> Also, I don't be= lieve a timer for the receipt of EoRR is

>>>>>>>> necessary, becau= se the EoRR is guaranteed.

>>>>>>>> Guaranteed means= "unless the session drops first".

>>>>>>>> --

>>>>>>>>

>>>>>>>> Jakob Heitz.

>>>>>>>>

>>>>>>>> ________________= ________________________

>>>>>>>> From: Chris Hall= [chris.hall@highwayman.com]

>>>>>>>> Sent: Saturday, = 25 January 2014 11:27 AM

>>>>>>>> To: i= dr@ietf.org

>>>>>>>> Cc: Jakob Heitz<= o:p>

>>>>>>>> Subject: RE: [Id= r] WG LC for

>>>>>>>> draft-ietf-idr-b= gp-enhanced-route-refresh

>>>>>>>>

>>>>>>>> Jakob Heitz wrot= e (on Fri 24-Jan-2014 at 20:37):

>>>>>>>> ...

>>>>>>>>> Silence mean= s don't do it.

>>>>>>>>

>>>>>>>> Hmmm.... as a pr= inciple I'm more comfortable with "that which

>>>>>>>> isn't prohibited= is permitted"....

>>>>>>>>

>>>>>>>>> You would de= finitely NOT want BoRR to flush old stales.

>>>>>>>>

>>>>>>>> ....but, given t= he definite requirement, and given that the

>>>>>>>> current preceden= t for "marking stale" does flush old stale,

>>>>>>>> then a few words= for the avoidance of doubt ?

>>>>>>>>

>>>>>>>>> Restarting t= he timer might be a good idea.

>>>>>>>>

>>>>>>>> I dunno... a rou= te which remains stale for "a long time" is, of

>>>>>>>> course, a candid= ate for being withdrawn: so having started a

>>>>>>>> timer the first = time things are set stale, I would avoid

>>>>>>>> extending that

>>>>>>>> -- at least for = Graceful Restart, where the whole withdraw

>>>>>>>> thing has been &= quot;on-hold" since the last session failed.  For

>>>>>>>> route-refresh I = guess there's more of a presumption that stale

>>>>>>>> routes will be r= efreshed sooner or later, and in the meantime

>>>>>>>> they remain good= .  So if the route-refresh is (repeatedly)

>>>>>>>> restarted for so= me reason, perhaps it is more reasonable to

>>>>>>>> extend the flush= deadline -- but avoid doing this indefinitely ?

>>>>>>>>

>>>>>>>> FWIW, for route-= refresh and for GR, the Adj-RIB-Out mechanics I

>>>>>>>> have built in Qu= agga prioritise route changes (pending changes

>>>>>>>> and any that occ= ur during the refresh) over refresh updates.

>>>>>>>> This makes it mo= re likely that remaining stale routes are still

> good.

>>>>>>>> But the other en= d cannot know that.

>>>>>>>>

>>>>>>>> The paragraph in= the draft discussing the "entire Adj-RIB-Out"

>>>>>>>> defines that to = be the entries present "at the start of the

>>>>>>>> route refresh op= eration", and observes that these comprise both

>>>>>>>> reachable and un= reachable routes.  [An "of" after "comprise"

>>>>>>>> sets teeth on ed= ge, BTW.]  I'm really not sure what this

>>>>>>>> paragraph is try= ing to tell me.

>>>>>>>> The reference to= unreachable routes appears to suggest that

>>>>>>>> pending withdraw= s should be sent as part of the refresh -- so

>>>>>>>> not left to the = EoRR to implement at the end.  The point at

>>>>>>>> which the EoRR i= s sent is defined such that it excludes any

>>>>>>>> Adj-RIB-Out entr= ies added after the route-refresh started, but

>>>>>>>> includes any whi= ch are changed during the process.  It seems

>>>>>>>> reasonable to de= lay any brand new reachable prefixes until

>>>>>>>> after all previo= usly announced ones have been refreshed and the

>>>>>>>> EoRR sent -- if = that's the

> intent here.

>>>>>>>> Changes which oc= cur before the refresh gets to a given entry

>>>>>>>> are pretty natur= ally swept up by the refresh.  Changes which

>>>>>>>> occur after the = refresh has gone past, could/should be deferred

>>>>>>>> to after the EoR= R ?

>>>>>>>> Does it make a d= ifference if the change is a withdraw ?  (Of

>>>>>>>> course MRAI may = kick in here.  Ah.  MRAI and route-refresh,

>>>>>>>> there's a topic<= o:p>

>>>>>>>> !)

>>>>>>>>

>>>>>>>> I think the esse= nce of the rule is that the EoRR should be sent

>>>>>>>> once  all p= refixes previously advertised to the peer as

>>>>>>>> reachable have&n= bsp; been refreshed, ie announced or withdrawn (at least) once.<= /p>

>>>>>>>> Or,  perhap= s more strictly, not *before* those prefixes have

>>>>>>>> *all* been = announced once -- given that the EoRR will promptly

>>>>>>>> bang un-advertis= ed stuff on the head.  Even more strictly

>>>>>>>> perhaps: not sen= d EoRR *before* any withdraws implied by it are

>>>>>>>> required or desi= rable.

>>>>>>>>

>>>>>>>> Depending on the= implementation, a given sender may or may not

>>>>>>>> be able to deter= mine the minimum set of updates required before

>>>>>>>> sending EoRR.

>>>>>>>>

>>>>>>>> If the refresh o= peration takes a long time, there may be good

>>>>>>>> routeing reasons= to arrange for some route changes to be sent

>>>>>>>> to the peer &quo= t;early" -- that is to send announcements which do

>>>>>>>> not contribute t= o the refresh, but which are important enough

>>>>>>>> to warrant delay= ing the end of the refresh.  That could be a

>>>>>>>> matter for<= /o:p>

>>>>>>>> recommendation(s= ) in the standard.

>>>>>>>>

>>>>>>>> NB: given that t= he timing of the EoRR is tied to the state of

>>>>>>>> the Adj-RIB-Out,= I'm not sure about the Graceful Restart

> assumptions.

>>>>>>>> At the beginning= of the initial update, the Restarting and

>>>>>>>> Receiving speake= rs have:

>>>>>>>>

>>>>>>>> Restarting: = ; Empty Adj-RIB-In   Empty Adj-RIB-Out

>>>>>>>>

>>>>>>>> Receiving: =   Empty Adj-RIB-Out  Stale Adj-RIB-In

>>>>>>>>

>>>>>>>> Now suppose (bon= kers or otherwise) the receiving speaker sends

>>>>>>>> an RRQ part way = through the initial update.  The restarting

>>>>>>>> speaker responds= with BoRR, everything in its Adj-RIB-Out, and

>>>>>>>> EoRR -- per spec= ification.  The receiving speaker sees the

>>>>>>>> EoRR, and flushe= s stale.  Unfortunately, if the restarting

>>>>>>>> speaker has not = yet fully populated its Adj-RIB-Out, then many

>>>>>>>> further routes w= ill be sent before the EoR falls due -- but the

>>>>>>>> receiving speake= r has already flushed their tiny posteriors :-(

>>>>>>>>

>>>>>>>> I am coming to t= he view that route-refresh during a Graceful

>>>>>>>> Restart initial = update is a horse of a different colour altogether.

>>>>>>>>

>>>>>>>> [So the assumpti= on that EoRR and EoR are triggered by the same

>>>>>>>> thing was comple= tely wrong, and I apologise for it.]

>>>>>>>>

>>>>>>>> Chris=

>>>>>>>>

>>>>>>>> ________________= _______________________________

>>>>>>>> Idr mailing list=

>>>>>>>> Idr@i= etf.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<= /span>

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

>>>

>>> ____________________________________= ___________

>>> Idr mailing list

>>> Idr@ietf.org

>>> htt= ps://www.ietf.org/mailman/listinfo/idr

>>

>> ________________________________________= _______

>> Idr mailing list

>> Idr@ietf.org<= /o:p>

>> 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_2F3EBB88EC3A454AAB08915FBF0B8C7E02F7116Feusaamb109erics_-- From sairay@cisco.com Wed Jan 29 18:06:28 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E99991A042F; Wed, 29 Jan 2014 18:06:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.035 X-Spam-Level: X-Spam-Status: No, score=-15.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gd_z5ECWTRw; Wed, 29 Jan 2014 18:06:19 -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 178751A0428; Wed, 29 Jan 2014 18:06:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=68970; q=dns/txt; s=iport; t=1391047576; x=1392257176; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ezAWS//HHuUTJHXprdieL6f8CCt5OUSQLhyZ9W8XtbU=; b=ge+66NGECEN6yVbnS3KcV9/ZxDVr1FT58UGC6gn6Mm9CXnWRFx+NqLZr JSJneUXoLskXVm6fWrYDHwFxuZwGUq4iCS32J7sKYUydNGHfs032scvq6 P9EJBeIcLsuZ6r8vzFq7BNt72rRUhswOsrJt8JzY89rj41WOGNejkFI8n Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmIFAI+y6VKtJXHA/2dsb2JhbABZgkhEOFe9G4ECFnSCJQEBAQMBAQEBFwESQQsFBwQCAQgRAwEBAQsWAQYHJwsUCQgCBAENBQiHdQgNqVeiAxMEjk4gDQQGAQaDHoEUBJRAlgeBQIFtgWgHOw X-IronPort-AV: E=Sophos;i="4.95,746,1384300800"; d="scan'208,217";a="300631807" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 30 Jan 2014 02:06:14 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s0U26DxG018676 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Jan 2014 02:06:13 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.24]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Wed, 29 Jan 2014 20:06:13 -0600 From: "Saikat Ray (sairay)" To: Jakob Heitz , Thomas Mangin Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPF5Kdim6y2NtdXEOlCixBVCgqkZqRnDwAgAFEnwCAAAwAgIAAC4cAgAARhoCAABveAIAABfyAgAAe+ICAABsuAIABU5kAgAAEDoCAAX73AIAABbuAgAHS7QCAAuS1AIAABIUAgAAC0YCAAAG5gIAAB0kAgAACCYCAAAM5gIAACciAgAAUgwCAACB8AP//m/cwgADYwYCAAML6kIAAa2sA//+dK8A= Date: Thu, 30 Jan 2014 02:06:13 +0000 Message-ID: <8ED5B0B0F5B4854A912480C1521F973A11AFCD2B@xmb-rcd-x13.cisco.com> References: <010801cf1c8c$6b1a0420$414e0c60$@ndzh.com> <8ED5B0B0F5B4854A912480C1521F973A11AFBD56@xmb-rcd-x13.cisco.com> <6D84FB20-2A48-4830-92F5-C81C5F4AA36A@exa-networks.co.uk> <8ED5B0B0F5B4854A912480C1521F973A11AFCCA6@xmb-rcd-x13.cisco.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F7116F@eusaamb109.ericsson.se> In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F7116F@eusaamb109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.166.25] Content-Type: multipart/alternative; boundary="_000_8ED5B0B0F5B4854A912480C1521F973A11AFCD2Bxmbrcdx13ciscoc_" MIME-Version: 1.0 Cc: "Keyur Patel \(keyupate\)" , "idr@ietf.org" , Susan Hares , "idr-bounces@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 02:06:28 -0000 --_000_8ED5B0B0F5B4854A912480C1521F973A11AFCD2Bxmbrcdx13ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Jakob Heitz [mailto:jakob.heitz@ericsson.com] Sent: Wednesday, January 29, 2014 5:53 PM To: Saikat Ray (sairay); Thomas Mangin Cc: Susan Hares; Jeff Tantsura; Keyur Patel (keyupate); idr-bounces@ietf.or= g; idr@ietf.org Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Yes Saikat, but... The intent is to verify the routing table that was supposed to have been bu= ilt with proper update messages. If an EoRR deletes an unexpected stale route, it should be logged and debug= ged. [SR] No disagreement there. My only point was that the draft should codify = the semantics of BoRR/EoRR so that implementations can make all corner case= s work correctly, instead of (or in addition to) discussing these corner ca= ses. Notwithstanding routes deleted by policy changes. For example, we should not invent a mass withdraw procedure like sending Bo= RR followed directly by EoRR without any intervening update messages. [SR] Well, it has already been invented by BoRR/EoRR ;) Perhaps the draft c= an beg the implementers to not use this WMD (or threaten them with syslogs)= :D I can see a few people gagging now :) Thanks, Jakob. From: Saikat Ray (sairay) [mailto:sairay@cisco.com] Sent: Wednesday, January 29, 2014 5:38 PM To: Thomas Mangin Cc: Susan Hares; Jeff Tantsura; Keyur Patel (keyupate); Jakob Heitz; idr-bo= unces@ietf.org; idr@ietf.org Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh The route may have been advertised before (and not (yet) withdrawn). Consid= er the example: +---+ +---+ | A +-----+ B | +---+ +---+ t=3D0: A sends three prefixes: 1.1.1.1/32, 2.2.2.2/32, 3.3.3.3/32, to B. t=3D1: B sends an (enhanced) route-refresh request to A. t=3D2: A sends BoRR to B. t=3D3: A sends 1.1.1.1/32 and 2.2.2.2/32 to B t=3D4: A sends EoRR to B. At this point, both A and B MUST treat 3.3.3.3/32 as withdrawn even though = there was no explicit withdraw sent for it. That means, A doesn't need to s= end an explicit withdraw for 3.3.3.3/32, and B must delete 3.3.3.3/32's pat= h from A. This is the core semantics of BoRR and EoRR and it takes care of all cases.= This implies, e.g., if the sender A want to ensure that a particular prefi= x, x.y.z.w/n, is not considered withdrawn by the receiver, then A MUST adve= rtise x.y.z.w/n following any BoRR (even in nested cases) *before* any EoRR= . -----Original Message----- From: Thomas Mangin [mailto:thomas.mangin@exa-networks.co.uk] Sent: Tuesday, January 28, 2014 11:50 PM To: Saikat Ray (sairay) Cc: Susan Hares; Jeff Tantsura; Keyur Patel (keyupate); Jakob Heitz; idr-bo= unces@ietf.org; idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hello Saikat, Why "both by the sender", if the route was not announced it is clearly with= drawn on the sender side and by definition if a route is not in the RR it h= as to be withdrawn - that said saying it can not harm .. Thomas Sent from my iPad > On 29 Jan 2014, at 01:03, "Saikat Ray \(sairay\)" > wrote: > > The draft should add a line mandating the actual semantics (instead of/in= addition to the procedures of mark-and-sweep). Something along the line: > > "Any route for which no update has been sent between a BoRR and the follo= wing EoRR MUST be considered withdrawn by both the sender and the receiver.= " > > The rest is really implementation (how to handle nested BoRR/EoRR or GR E= oR, etc.), IMHO. > > I support the draft, BTW. > > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares > Sent: Tuesday, January 28, 2014 4:53 PM > To: 'Jeff Tantsura'; Keyur Patel (keyupate); 'Jakob Heitz'; 'Thomas > Mangin'; idr-bounces@ietf.org > Cc: idr@ietf.org > Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh > > Any other comments? (support/discussion accepted) > > Sue Hares > > PS - Keyur - spin a draft with this change and end it to me. > > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jeff Tantsura > Sent: Tuesday, January 28, 2014 5:56 PM > To: Keyur Patel (keyupate); Jakob Heitz; Thomas Mangin; > idr-bounces@ietf.org > Cc: idr@ietf.org > Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh > > I support the wording below. > > Cheers, > Jeff > > > -----Original Message----- > From: "keyupate@cisco.com" > > Date: Tuesday, January 28, 2014 1:43 PM > To: "keyupate@cisco.com" >, Jakob Heitz >, Thomas Mangin >, "idr-bounces@ietf.org" > > > Cc: "idr@ietf.org" > > Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh > >> Hi Jakob, >> >> How about the following (based on your suggestion): >> >> For a BGP speaker that supports the BGP Graceful Restart specified in >> [RFC4724] , it MUST NOT send a BoRR for an AFI/SAFI to a neighbor >> before it sends the EOR for the AFI/SAFI to the neighbor. This >> procedure would help the neighbor avoid the premature cleanup of >> stale routes. >> >> >> This would help simplify receiver side implementation wrt GR and >> Enhanced RR. :) >> >> Regards, >> Keyur >> >>> On 1/28/14 1:08 PM, "Keyur Patel (keyupate)" > wrote: >>> >>> Sure! I am saying you can simplify the implementation by simply >>> delaying the servicing of the route refresh reply till the >>> generation of > an EOR. >>> >>> Question is do we allow the text to be flexible enough to cover the >>> other case. :) >>> >>> Regards, >>> Keyur >>> >>>> On 1/28/14 12:56 PM, "Jakob Heitz" > wrote: >>>> >>>> Could we please simplify this a bit, not to force implementations >>>> to use different stale bits? >>>> >>>> Thanks, >>>> Jakob. >>>> >>>> -----Original Message----- >>>> From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] >>>> Sent: Tuesday, January 28, 2014 12:49 PM >>>> To: Jakob Heitz; Thomas Mangin; idr-bounces@ietf.org >>>> Cc: idr@ietf.org >>>> Subject: Re: [Idr] WG LC for >>>> draft-ietf-idr-bgp-enhanced-route-refresh >>>> >>>> >>>> >>>>> On 1/28/14 12:23 PM, "Jakob Heitz" > wrote: >>>>> >>>>> the order BoRR, EoR, EoRR allows this possible scenario: >>>>> >>>>> Suppose 2 routes exist :1.1.1.1/32, 2.2.2.2/32 The order could now be= : >>>>> . start session >>>>> . send 1.1.1.1/32 >>>>> . receive route refresh request. >>>>> . send BoRR >>>>> . send 2.2.2.2/32 >>>>> . send EoR >>>>> . send 1.1.1.1/32 >>>>> . send EoRR >>>>> >>>>> On receipt of EoR, the receiver could delete stales, deleting >>>>> 1.1.1.1/32. >>>> >>>> Not if you use different flags/bits to mark them stale? >>>> >>>> Implementations could choose to always postpone the route refresh >>>> reply and get the same behavior? >>>> >>>> Regards, >>>> Keyur >>>> >>>>> >>>>> Thanks, >>>>> Jakob. >>>>> >>>>> -----Original Message----- >>>>> From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] >>>>> Sent: Tuesday, January 28, 2014 12:17 PM >>>>> To: Jakob Heitz; Thomas Mangin; idr-bounces@ietf.org >>>>> Cc: idr@ietf.org >>>>> Subject: Re: [Idr] WG LC for >>>>> draft-ietf-idr-bgp-enhanced-route-refresh >>>>> >>>>> The order: BoRR, EoR, EoRR lets an implementation do both, merge >>>>> route refresh reply with an initial table announcement or delay >>>>> the route refresh replies. As long as EoR is sent before EoRR >>>>> there should be no issue right? >>>>> >>>>> Regards, >>>>> Keyur >>>>>> On 1/28/14 12:06 PM, "Jakob Heitz" > wrote: >>>>>> >>>>>> Enke's text allows the order: BoRR, EoR, EoRR. >>>>>> >>>>>> Could we change Enke's text from >>>>>> "it MUST NOT send an EoRR" to >>>>>> "it MUST NOT send an BoRR" >>>>>> >>>>>> Thanks, >>>>>> Jakob. >>>>>> >>>>>> -----Original Message----- >>>>>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Keyur Patel >>>>>> (keyupate) >>>>>> Sent: Tuesday, January 28, 2014 11:51 AM >>>>>> To: Thomas Mangin; idr-bounces@ietf.org >>>>>> Cc: idr@ietf.org >>>>>> Subject: Re: [Idr] WG LC for >>>>>> draft-ietf-idr-bgp-enhanced-route-refresh >>>>>> >>>>>> Hi Jacob, Thomas, >>>>>> >>>>>> Am ok with implementations delaying the servicing of route >>>>>> refresh request. Enke's suggested text addresses the concern. >>>>>> >>>>>> Best Regards, >>>>>> Keyur >>>>>> >>>>>> On 1/26/14 3:39 PM, "Thomas Mangin" >>>>>> > >>>>>> wrote: >>>>>> >>>>>>> Damn, time to practice then :) >>>>>>> >>>>>>> Joke apart, I agree with this post. The feature should not be >>>>>>> used ( and ignored ) until the initial route exchange has been comp= leted. >>>>>>> >>>>>>> If the session drops, I would expect the router to cancel any RR >>>>>>> which was ongoing as the AdjRIBOut is going to be retransmitted >>>>>>> anyway. >>>>>>> >>>>>>> Thomas >>>>>>> >>>>>>> Sent from my iPad >>>>>>> >>>>>>>> On 25 Jan 2014, at 19:48, Jakob Heitz >>>>>>>> > >>>>>>>> wrote: >>>>>>>> >>>>>>>> RFCs are written for coders "practiced" in the art". >>>>>>>> If anyone sends an EoRR before the adj-RIB-out is fully >>>>>>>> populated, then it's a BUG. >>>>>>>> This does not need to be said. >>>>>>>> >>>>>>>> Personally, I believe a route refresh request should not be >>>>>>>> honored until GR is complete. >>>>>>>> Also, I don't believe a timer for the receipt of EoRR is >>>>>>>> necessary, because the EoRR is guaranteed. >>>>>>>> Guaranteed means "unless the session drops first". >>>>>>>> -- >>>>>>>> >>>>>>>> Jakob Heitz. >>>>>>>> >>>>>>>> ________________________________________ >>>>>>>> From: Chris Hall [chris.hall@highwayman.com] >>>>>>>> Sent: Saturday, 25 January 2014 11:27 AM >>>>>>>> To: idr@ietf.org >>>>>>>> Cc: Jakob Heitz >>>>>>>> Subject: RE: [Idr] WG LC for >>>>>>>> draft-ietf-idr-bgp-enhanced-route-refresh >>>>>>>> >>>>>>>> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): >>>>>>>> ... >>>>>>>>> Silence means don't do it. >>>>>>>> >>>>>>>> Hmmm.... as a principle I'm more comfortable with "that which >>>>>>>> isn't prohibited is permitted".... >>>>>>>> >>>>>>>>> You would definitely NOT want BoRR to flush old stales. >>>>>>>> >>>>>>>> ....but, given the definite requirement, and given that the >>>>>>>> current precedent for "marking stale" does flush old stale, >>>>>>>> then a few words for the avoidance of doubt ? >>>>>>>> >>>>>>>>> Restarting the timer might be a good idea. >>>>>>>> >>>>>>>> I dunno... a route which remains stale for "a long time" is, of >>>>>>>> course, a candidate for being withdrawn: so having started a >>>>>>>> timer the first time things are set stale, I would avoid >>>>>>>> extending that >>>>>>>> -- at least for Graceful Restart, where the whole withdraw >>>>>>>> thing has been "on-hold" since the last session failed. For >>>>>>>> route-refresh I guess there's more of a presumption that stale >>>>>>>> routes will be refreshed sooner or later, and in the meantime >>>>>>>> they remain good. So if the route-refresh is (repeatedly) >>>>>>>> restarted for some reason, perhaps it is more reasonable to >>>>>>>> extend the flush deadline -- but avoid doing this indefinitely ? >>>>>>>> >>>>>>>> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I >>>>>>>> have built in Quagga prioritise route changes (pending changes >>>>>>>> and any that occur during the refresh) over refresh updates. >>>>>>>> This makes it more likely that remaining stale routes are still > good. >>>>>>>> But the other end cannot know that. >>>>>>>> >>>>>>>> The paragraph in the draft discussing the "entire Adj-RIB-Out" >>>>>>>> defines that to be the entries present "at the start of the >>>>>>>> route refresh operation", and observes that these comprise both >>>>>>>> reachable and unreachable routes. [An "of" after "comprise" >>>>>>>> sets teeth on edge, BTW.] I'm really not sure what this >>>>>>>> paragraph is trying to tell me. >>>>>>>> The reference to unreachable routes appears to suggest that >>>>>>>> pending withdraws should be sent as part of the refresh -- so >>>>>>>> not left to the EoRR to implement at the end. The point at >>>>>>>> which the EoRR is sent is defined such that it excludes any >>>>>>>> Adj-RIB-Out entries added after the route-refresh started, but >>>>>>>> includes any which are changed during the process. It seems >>>>>>>> reasonable to delay any brand new reachable prefixes until >>>>>>>> after all previously announced ones have been refreshed and the >>>>>>>> EoRR sent -- if that's the > intent here. >>>>>>>> Changes which occur before the refresh gets to a given entry >>>>>>>> are pretty naturally swept up by the refresh. Changes which >>>>>>>> occur after the refresh has gone past, could/should be deferred >>>>>>>> to after the EoRR ? >>>>>>>> Does it make a difference if the change is a withdraw ? (Of >>>>>>>> course MRAI may kick in here. Ah. MRAI and route-refresh, >>>>>>>> there's a topic >>>>>>>> !) >>>>>>>> >>>>>>>> I think the essence of the rule is that the EoRR should be sent >>>>>>>> once all prefixes previously advertised to the peer as >>>>>>>> reachable have been refreshed, ie announced or withdrawn (at leas= t) once. >>>>>>>> Or, perhaps more strictly, not *before* those prefixes have >>>>>>>> *all* been announced once -- given that the EoRR will promptly >>>>>>>> bang un-advertised stuff on the head. Even more strictly >>>>>>>> perhaps: not send EoRR *before* any withdraws implied by it are >>>>>>>> required or desirable. >>>>>>>> >>>>>>>> Depending on the implementation, a given sender may or may not >>>>>>>> be able to determine the minimum set of updates required before >>>>>>>> sending EoRR. >>>>>>>> >>>>>>>> If the refresh operation takes a long time, there may be good >>>>>>>> routeing reasons to arrange for some route changes to be sent >>>>>>>> to the peer "early" -- that is to send announcements which do >>>>>>>> not contribute to the refresh, but which are important enough >>>>>>>> to warrant delaying the end of the refresh. That could be a >>>>>>>> matter for >>>>>>>> recommendation(s) in the standard. >>>>>>>> >>>>>>>> NB: given that the timing of the EoRR is tied to the state of >>>>>>>> the Adj-RIB-Out, I'm not sure about the Graceful Restart > assumptions. >>>>>>>> At the beginning of the initial update, the Restarting and >>>>>>>> Receiving speakers have: >>>>>>>> >>>>>>>> Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out >>>>>>>> >>>>>>>> Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In >>>>>>>> >>>>>>>> Now suppose (bonkers or otherwise) the receiving speaker sends >>>>>>>> an RRQ part way through the initial update. The restarting >>>>>>>> speaker responds with BoRR, everything in its Adj-RIB-Out, and >>>>>>>> EoRR -- per specification. The receiving speaker sees the >>>>>>>> EoRR, and flushes stale. Unfortunately, if the restarting >>>>>>>> speaker has not yet fully populated its Adj-RIB-Out, then many >>>>>>>> further routes will be sent before the EoR falls due -- but the >>>>>>>> receiving speaker has already flushed their tiny posteriors :-( >>>>>>>> >>>>>>>> I am coming to the view that route-refresh during a Graceful >>>>>>>> Restart initial update is a horse of a different colour altogether= . >>>>>>>> >>>>>>>> [So the assumption that EoRR and EoR are triggered by the same >>>>>>>> thing was completely wrong, and I apologise for it.] >>>>>>>> >>>>>>>> Chris >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >> >> _______________________________________________ >> 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_8ED5B0B0F5B4854A912480C1521F973A11AFCD2Bxmbrcdx13ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From: Jakob He= itz [mailto:jakob.heitz@ericsson.com]
Sent: Wednesday, January 29, 2014 5:53 PM
To: Saikat Ray (sairay); Thomas Mangin
Cc: Susan Hares; Jeff Tantsura; Keyur Patel (keyupate); idr-bounces@= ietf.org; idr@ietf.org
Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refre= sh

 

Yes Saikat, but…=

 

The intent is to verif= y the routing table that was supposed to have been built with proper update= messages.

If an EoRR deletes an = unexpected stale route, it should be logged and debugged.

 <= /p>

[SR] No disagreement ther= e. My only point was that the draft should codify the semantics of BoRR/EoR= R so that implementations can make all corner cases work correctly, instead= of (or in addition to) discussing these corner cases.

 <= /p>

Notwithstanding routes= deleted by policy changes.

For example, we should= not invent a mass withdraw procedure like sending BoRR followed directly b= y EoRR without any intervening update messages.

 <= /p>

[SR] Well, it has already= been invented by BoRR/EoRR ;) Perhaps the draft can beg the implementers t= o not use this WMD (or threaten them with syslogs) :D

 <= /p>

I can see a few people= gagging now J

 

Thanks,

Jakob.

 

 

The route may have been advertised before (and no= t (yet) withdrawn). Consider the example:

 

+---+     +---+

| A +-----+ B |

+---+     +---+

 

t=3D0: A sends three prefixes: 1.1.1.1/32, 2.2.2.= 2/32, 3.3.3.3/32, to B.

t=3D1: B sends an (enhanced) route-refresh reques= t to A.

t=3D2: A sends BoRR to B.

t=3D3: A sends 1.1.1.1/32 and 2.2.2.2/32 to B

t=3D4: A sends EoRR to B.

 

At this point, both A and B MUST treat 3.3.3.3/32= as withdrawn even though there was no explicit withdraw sent for it. That = means, A doesn’t need to send an explicit withdraw for 3.3.3.3/32, an= d B must delete 3.3.3.3/32’s path from A.

 

This is the core semantics of BoRR and EoRR and i= t takes care of all cases. This implies, e.g., if the sender A want to ensu= re that a particular prefix, x.y.z.w/n, is not considered withdrawn by the = receiver, then A MUST advertise x.y.z.w/n following any BoRR (even in nested cases) *before* any EoRR.

 

-----Original Message-----
From: Thomas Mangin [ma= ilto:thomas.mangin@exa-networks.co.uk]
Sent: Tuesday, January 28, 2014 11:50 PM
To: Saikat Ray (sairay)
Cc: Susan Hares; Jeff Tantsura; Keyur Patel (keyupate); Jakob Heitz; idr-bounces@ietf.org; idr@ietf.org<= br> Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh=

 

Hello Saikat,

 

Why "both by the sender", if the route = was not announced it is clearly withdrawn on the sender side and by definit= ion if a route is not in the RR it has to be withdrawn - that said saying i= t can not harm ..

 

Thomas

 

Sent from my iPad

 

> On 29 Jan 2014, at 01:03, "Saikat Ray \= (sairay\)" <sairay@cisco.com> wrote:

>

> The draft should add a line mandating the ac= tual semantics (instead of/in addition to the procedures of mark-and-sweep)= . Something along the line:

>

> "Any route for which no update has been= sent between a BoRR and the following EoRR MUST be considered withdrawn by= both the sender and the receiver."

>

> The rest is really implementation (how to ha= ndle nested BoRR/EoRR or GR EoR, etc.), IMHO.

>

> I support the draft, BTW.

>

> -----Original Message-----

> From: Idr [mailto:idr-bou= nces@ietf.org] On Behalf Of Susan Hares

> Sent: Tuesday, January 28, 2014 4:53 PM=

> To: 'Jeff Tantsura'; Keyur Patel (keyupate);= 'Jakob Heitz'; 'Thomas

> Mangin'; idr-bounces@ietf= .org

> Cc: idr@ietf.org<= /o:p>

> Subject: Re: [Idr] WG LC for draft-ietf-idr-= bgp-enhanced-route-refresh

>

> Any other comments?  (support/discussio= n accepted)

>

> Sue Hares

>

> PS - Keyur - spin a draft with this change a= nd end it to me.

>

> -----Original Message-----

> From: Idr [mailto:idr-bou= nces@ietf.org] On Behalf Of Jeff Tantsura

> Sent: Tuesday, January 28, 2014 5:56 PM=

> To: Keyur Patel (keyupate); Jakob Heitz; Tho= mas Mangin;

> idr-bounces@ietf.org

> Cc: idr@ietf.org<= /o:p>

> Subject: Re: [Idr] WG LC for draft-ietf-idr-= bgp-enhanced-route-refresh

>

> I support the wording below.

>

> Cheers,

> Jeff

>

>

> -----Original Message-----

> From: "keyupate@cisco.= com" <keyupate@cisco.com>= ;

> Date: Tuesday, January 28, 2014 1:43 PM=

> To: "keyupate@cisco.co= m" <keyupate@cisco.com>, Jakob Heitz <jakob.heitz@ericsson.com= >, Thomas Mangin <thomas.mangin@exa-ne= tworks.co.uk>, "idr-bounces@ietf.org"<= /p>

> <= idr-bounces@ietf.org<= /span>>

> Cc: "idr@ietf.org= " <idr@ietf.org>

> Subject: Re: [Idr] WG LC for draft-ietf-idr-= bgp-enhanced-route-refresh

>

>> Hi Jakob,

>>

>> How about the following (based on your s= uggestion):

>>

>> For a BGP speaker that supports the BGP = Graceful Restart specified in

>> [RFC4724] , it MUST NOT send a BoRR for = an AFI/SAFI to a neighbor

>> before it sends the EOR for the AFI/SAFI= to the neighbor.  This

>> procedure would help the neighbor avoid = the premature cleanup of

>> stale routes.

>>

>>

>> This would help simplify receiver side i= mplementation wrt GR and

>> Enhanced RR. :)

>>

>> Regards,

>> Keyur

>>

>>> On 1/28/14 1:08 PM, "Keyur Pate= l (keyupate)" <keyupate@cisco.com> w= rote:

>>>

>>> Sure! I am saying you can simplify t= he implementation by simply

>>> delaying the servicing of the route = refresh reply till the

>>> generation of

> an EOR.

>>>

>>> Question is do we allow the text to = be flexible enough to cover the

>>> other case. :)

>>>

>>> Regards,

>>> Keyur

>>>

>>>> On 1/28/14 12:56 PM, "Jakob= Heitz" <jakob.heitz@ericsson.com= > wrote:

>>>>

>>>> Could we please simplify this a = bit, not to force implementations

>>>> to use different stale bits?

>>>>

>>>> Thanks,

>>>> Jakob.

>>>>

>>>> -----Original Message-----<= /o:p>

>>>> From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com]

>>>> Sent: Tuesday, January 28, 2014 = 12:49 PM

>>>> To: Jakob Heitz; Thomas Mangin; = idr-bounces@ietf.org<= /span>

>>>> Cc: idr@ietf.org

>>>> Subject: Re: [Idr] WG LC for

>>>> draft-ietf-idr-bgp-enhanced-rout= e-refresh

>>>>

>>>>

>>>>

>>>>> On 1/28/14 12:23 PM, "J= akob Heitz" <jakob.heitz@ericsson.com= > wrote:

>>>>>

>>>>> the order BoRR, EoR, EoRR al= lows this possible scenario:

>>>>>

>>>>> Suppose 2 routes exist :1.1.= 1.1/32, 2.2.2.2/32 The order could now be:

>>>>> . start session

>>>>> . send 1.1.1.1/32=

>>>>> . receive route refresh requ= est.

>>>>> . send BoRR

>>>>> . send 2.2.2.2/32=

>>>>> . send EoR

>>>>> . send 1.1.1.1/32=

>>>>> . send EoRR

>>>>>

>>>>> On receipt of EoR, the recei= ver could delete stales, deleting

>>>>> 1.1.1.1/32.

>>>>

>>>> Not if you use different flags/b= its to mark them stale?

>>>>

>>>> Implementations could choose to = always postpone the route refresh

>>>> reply and get the same behavior?=

>>>>

>>>> Regards,

>>>> Keyur

>>>>

>>>>>

>>>>> Thanks,

>>>>> Jakob.

>>>>>

>>>>> -----Original Message-----

>>>>> From: Keyur Patel (keyupate)= [mailto:keyupate@cisco.com]

>>>>> Sent: Tuesday, January 28, 2= 014 12:17 PM

>>>>> To: Jakob Heitz; Thomas Mang= in; idr-bounces@ietf.org<= /span>

>>>>> Cc: idr@ietf.org<= /span>

>>>>> Subject: Re: [Idr] WG LC for=

>>>>> draft-ietf-idr-bgp-enhanced-= route-refresh

>>>>>

>>>>> The order: BoRR, EoR, EoRR l= ets an implementation do both,  merge

>>>>> route refresh reply with an = initial table announcement or delay

>>>>> the route refresh replies. A= s long as EoR is sent before EoRR

>>>>> there should be no issue rig= ht?

>>>>>

>>>>> Regards,

>>>>> Keyur

>>>>>> On 1/28/14 12:06 PM, &qu= ot;Jakob Heitz" <jakob.heitz@ericsson.com> wrote:

>>>>>>

>>>>>> Enke's text allows the o= rder: BoRR, EoR, EoRR.

>>>>>>

>>>>>> Could we change Enke's t= ext from

>>>>>> "it MUST NOT send a= n EoRR" to

>>>>>> "it MUST NOT send a= n BoRR"

>>>>>>

>>>>>> Thanks,

>>>>>> Jakob.

>>>>>>

>>>>>> -----Original Message---= --

>>>>>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Keyur Patel=

>>>>>> (keyupate)

>>>>>> Sent: Tuesday, January 2= 8, 2014 11:51 AM

>>>>>> To: Thomas Mangin; idr-bounces@ietf.org<= /span>

>>>>>> Cc: idr@ietf.= org

>>>>>> Subject: Re: [Idr] WG LC= for

>>>>>> draft-ietf-idr-bgp-enhan= ced-route-refresh

>>>>>>

>>>>>> Hi Jacob, Thomas,

>>>>>>

>>>>>> Am ok with implementatio= ns delaying the servicing of route

>>>>>> refresh request. Enke's = suggested text addresses the concern.

>>>>>>

>>>>>> Best Regards,=

>>>>>> Keyur

>>>>>>

>>>>>> On 1/26/14 3:39 PM, &quo= t;Thomas Mangin"

>>>>>> <thomas.mangin@exa-networks.co.uk>

>>>>>> wrote:

>>>>>>

>>>>>>> Damn, time to practi= ce then :)

>>>>>>>

>>>>>>> Joke apart, I agree = with this post. The feature should not be

>>>>>>> used ( and ignored )= until the initial route exchange has been completed.

>>>>>>>

>>>>>>> If the session drops= , I would expect the router to cancel any RR

>>>>>>> which was ongoing as= the AdjRIBOut is going to be retransmitted

>>>>>>> anyway.

>>>>>>>

>>>>>>> Thomas

>>>>>>>

>>>>>>> Sent from my iPad

>>>>>>>

>>>>>>>> On 25 Jan 2014, = at 19:48, Jakob Heitz

>>>>>>>> <jakob.heitz@ericsson.com>

>>>>>>>> wrote:

>>>>>>>>

>>>>>>>> RFCs are written= for coders "practiced" in the art".

>>>>>>>> If anyone sends = an EoRR before the adj-RIB-out is fully

>>>>>>>> populated, then = it's a BUG.

>>>>>>>> This does not ne= ed to be said.

>>>>>>>>

>>>>>>>> Personally, I be= lieve a route refresh request should not be

>>>>>>>> honored until GR= is complete.

>>>>>>>> Also, I don't be= lieve a timer for the receipt of EoRR is

>>>>>>>> necessary, becau= se the EoRR is guaranteed.

>>>>>>>> Guaranteed means= "unless the session drops first".

>>>>>>>> --

>>>>>>>>

>>>>>>>> Jakob Heitz.

>>>>>>>>

>>>>>>>> ________________= ________________________

>>>>>>>> From: Chris Hall= [chris.hall@highwayman.com]

>>>>>>>> Sent: Saturday, = 25 January 2014 11:27 AM

>>>>>>>> To: i= dr@ietf.org

>>>>>>>> Cc: Jakob Heitz<= o:p>

>>>>>>>> Subject: RE: [Id= r] WG LC for

>>>>>>>> draft-ietf-idr-b= gp-enhanced-route-refresh

>>>>>>>>

>>>>>>>> Jakob Heitz wrot= e (on Fri 24-Jan-2014 at 20:37):

>>>>>>>> ...

>>>>>>>>> Silence mean= s don't do it.

>>>>>>>>

>>>>>>>> Hmmm.... as a pr= inciple I'm more comfortable with "that which

>>>>>>>> isn't prohibited= is permitted"....

>>>>>>>>

>>>>>>>>> You would de= finitely NOT want BoRR to flush old stales.

>>>>>>>>

>>>>>>>> ....but, given t= he definite requirement, and given that the

>>>>>>>> current preceden= t for "marking stale" does flush old stale,

>>>>>>>> then a few words= for the avoidance of doubt ?

>>>>>>>>

>>>>>>>>> Restarting t= he timer might be a good idea.

>>>>>>>>

>>>>>>>> I dunno... a rou= te which remains stale for "a long time" is, of

>>>>>>>> course, a candid= ate for being withdrawn: so having started a

>>>>>>>> timer the first = time things are set stale, I would avoid

>>>>>>>> extending that

>>>>>>>> -- at least for = Graceful Restart, where the whole withdraw

>>>>>>>> thing has been &= quot;on-hold" since the last session failed.  For

>>>>>>>> route-refresh I = guess there's more of a presumption that stale

>>>>>>>> routes will be r= efreshed sooner or later, and in the meantime

>>>>>>>> they remain good= .  So if the route-refresh is (repeatedly)

>>>>>>>> restarted for so= me reason, perhaps it is more reasonable to

>>>>>>>> extend the flush= deadline -- but avoid doing this indefinitely ?

>>>>>>>>

>>>>>>>> FWIW, for route-= refresh and for GR, the Adj-RIB-Out mechanics I

>>>>>>>> have built in Qu= agga prioritise route changes (pending changes

>>>>>>>> and any that occ= ur during the refresh) over refresh updates.

>>>>>>>> This makes it mo= re likely that remaining stale routes are still

> good.

>>>>>>>> But the other en= d cannot know that.

>>>>>>>>

>>>>>>>> The paragraph in= the draft discussing the "entire Adj-RIB-Out"

>>>>>>>> defines that to = be the entries present "at the start of the

>>>>>>>> route refresh op= eration", and observes that these comprise both

>>>>>>>> reachable and un= reachable routes.  [An "of" after "comprise"

>>>>>>>> sets teeth on ed= ge, BTW.]  I'm really not sure what this

>>>>>>>> paragraph is try= ing to tell me.

>>>>>>>> The reference to= unreachable routes appears to suggest that

>>>>>>>> pending withdraw= s should be sent as part of the refresh -- so

>>>>>>>> not left to the = EoRR to implement at the end.  The point at

>>>>>>>> which the EoRR i= s sent is defined such that it excludes any

>>>>>>>> Adj-RIB-Out entr= ies added after the route-refresh started, but

>>>>>>>> includes any whi= ch are changed during the process.  It seems

>>>>>>>> reasonable to de= lay any brand new reachable prefixes until

>>>>>>>> after all previo= usly announced ones have been refreshed and the

>>>>>>>> EoRR sent -- if = that's the

> intent here.

>>>>>>>> Changes which oc= cur before the refresh gets to a given entry

>>>>>>>> are pretty natur= ally swept up by the refresh.  Changes which

>>>>>>>> occur after the = refresh has gone past, could/should be deferred

>>>>>>>> to after the EoR= R ?

>>>>>>>> Does it make a d= ifference if the change is a withdraw ?  (Of

>>>>>>>> course MRAI may = kick in here.  Ah.  MRAI and route-refresh,

>>>>>>>> there's a topic<= o:p>

>>>>>>>> !)

>>>>>>>>

>>>>>>>> I think the esse= nce of the rule is that the EoRR should be sent

>>>>>>>> once  all p= refixes previously advertised to the peer as

>>>>>>>> reachable have&n= bsp; been refreshed, ie announced or withdrawn (at least) once.<= /p>

>>>>>>>> Or,  perhap= s more strictly, not *before* those prefixes have

>>>>>>>> *all* been = announced once -- given that the EoRR will promptly

>>>>>>>> bang un-advertis= ed stuff on the head.  Even more strictly

>>>>>>>> perhaps: not sen= d EoRR *before* any withdraws implied by it are

>>>>>>>> required or desi= rable.

>>>>>>>>

>>>>>>>> Depending on the= implementation, a given sender may or may not

>>>>>>>> be able to deter= mine the minimum set of updates required before

>>>>>>>> sending EoRR.

>>>>>>>>

>>>>>>>> If the refresh o= peration takes a long time, there may be good

>>>>>>>> routeing reasons= to arrange for some route changes to be sent

>>>>>>>> to the peer &quo= t;early" -- that is to send announcements which do

>>>>>>>> not contribute t= o the refresh, but which are important enough

>>>>>>>> to warrant delay= ing the end of the refresh.  That could be a

>>>>>>>> matter for<= /o:p>

>>>>>>>> recommendation(s= ) in the standard.

>>>>>>>>

>>>>>>>> NB: given that t= he timing of the EoRR is tied to the state of

>>>>>>>> the Adj-RIB-Out,= I'm not sure about the Graceful Restart

> assumptions.

>>>>>>>> At the beginning= of the initial update, the Restarting and

>>>>>>>> Receiving speake= rs have:

>>>>>>>>

>>>>>>>> Restarting: = ; Empty Adj-RIB-In   Empty Adj-RIB-Out

>>>>>>>>

>>>>>>>> Receiving: =   Empty Adj-RIB-Out  Stale Adj-RIB-In

>>>>>>>>

>>>>>>>> Now suppose (bon= kers or otherwise) the receiving speaker sends

>>>>>>>> an RRQ part way = through the initial update.  The restarting

>>>>>>>> speaker responds= with BoRR, everything in its Adj-RIB-Out, and

>>>>>>>> EoRR -- per spec= ification.  The receiving speaker sees the

>>>>>>>> EoRR, and flushe= s stale.  Unfortunately, if the restarting

>>>>>>>> speaker has not = yet fully populated its Adj-RIB-Out, then many

>>>>>>>> further routes w= ill be sent before the EoR falls due -- but the

>>>>>>>> receiving speake= r has already flushed their tiny posteriors :-(

>>>>>>>>

>>>>>>>> I am coming to t= he view that route-refresh during a Graceful

>>>>>>>> Restart initial = update is a horse of a different colour altogether.

>>>>>>>>

>>>>>>>> [So the assumpti= on that EoRR and EoR are triggered by the same

>>>>>>>> thing was comple= tely wrong, and I apologise for it.]

>>>>>>>>

>>>>>>>> Chris=

>>>>>>>>

>>>>>>>> ________________= _______________________________

>>>>>>>> Idr mailing list=

>>>>>>>> Idr@i= etf.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<= /span>

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

>>>

>>> ____________________________________= ___________

>>> Idr mailing list

>>> Idr@ietf.org

>>> htt= ps://www.ietf.org/mailman/listinfo/idr

>>

>> ________________________________________= _______

>> Idr mailing list

>> Idr@ietf.org<= /o:p>

>> 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_8ED5B0B0F5B4854A912480C1521F973A11AFCD2Bxmbrcdx13ciscoc_-- From thomas.mangin@exa-networks.co.uk Wed Jan 29 23:27:18 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94BD61A0476; Wed, 29 Jan 2014 23:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vqde8qdQjcOx; Wed, 29 Jan 2014 23:27:11 -0800 (PST) Received: from out-7.mail.exa.net.uk (out-7.mail.exa.net.uk [82.219.4.135]) by ietfa.amsl.com (Postfix) with ESMTP id B02A71A04E5; Wed, 29 Jan 2014 23:27:10 -0800 (PST) Received: from smtp-3.mail.exa.net.uk (smtp-3.mail.exa.net.uk [82.219.5.3]) by out-7.mail.exa.net.uk (ExaSMTPD) with ESMTP id 10465A0056; Thu, 30 Jan 2014 07:27:06 +0000 (GMT) Received: from [192.168.1.14] (ptr-1.212.219.82.rev.exa.net.uk [82.219.212.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: thomas@mangin.com) by smtp-3.mail.exa.net.uk (ExaSMTPD) with ESMTPSA id BECE06C0047; Thu, 30 Jan 2014 07:27:03 +0000 (GMT) Content-Type: multipart/signed; boundary="Apple-Mail=_837DCAB4-CC25-4FDF-A030-81E2A962E82C"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Mangin In-Reply-To: <8ED5B0B0F5B4854A912480C1521F973A11AFCCA6@xmb-rcd-x13.cisco.com> Date: Thu, 30 Jan 2014 07:27:01 +0000 Message-Id: <04DD2BBD-D4A1-4297-BDBA-E2B2580803CD@exa-networks.co.uk> References: <010801cf1c8c$6b1a0420$414e0c60$@ndzh.com> <8ED5B0B0F5B4854A912480C1521F973A11AFBD56@xmb-rcd-x13.cisco.com> <6D84FB20-2A48-4830-92F5-C81C5F4AA36A@exa-networks.co.uk> <8ED5B0B0F5B4854A912480C1521F973A11AFCCA6@xmb-rcd-x13.cisco.com> To: sairay@cisco.com X-Mailer: Apple Mail (2.1827) X-Virus-Scanned: clamav-milter 0.97.8 at out-2-2.mail.exa.net.uk X-Virus-Status: Clean Cc: "idr@ietf.org" , "Keyur Patel \(keyupate\)" , "idr-bounces@ietf.org" , Susan Hares Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 07:27:18 -0000 --Apple-Mail=_837DCAB4-CC25-4FDF-A030-81E2A962E82C Content-Type: multipart/alternative; boundary="Apple-Mail=_7F0681F1-6802-491D-831B-DA99F342BAD3" --Apple-Mail=_7F0681F1-6802-491D-831B-DA99F342BAD3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello Sairay, Thank you for taking the time to put this flow together. Appreciated. = This is how I understood the router behaviour too. What I was = questioning was the need to have the word "sender" in the sentence. The following wording should cover this case IMHO : "Any route for which no update has been sent between a BoRR and the = following EoRR MUST be considered withdrawn by the receiver" or even = shorter "Any route for which no update has been sent between a BoRR and the = following EoRR MUST be considered withdrawn" I was trying to understand why you felt the need to specify the sender, = where the route is already withdrawn as the RR did not contain it ... Thomas On 30 Jan 2014, at 01:38, Saikat Ray (sairay) wrote: > The route may have been advertised before (and not (yet) withdrawn). = Consider the example: > =20 > +---+ +---+ > | A +-----+ B | > +---+ +---+ > =20 > t=3D0: A sends three prefixes: 1.1.1.1/32, 2.2.2.2/32, 3.3.3.3/32, to = B. > t=3D1: B sends an (enhanced) route-refresh request to A. > t=3D2: A sends BoRR to B. > t=3D3: A sends 1.1.1.1/32 and 2.2.2.2/32 to B > t=3D4: A sends EoRR to B. > =20 > At this point, both A and B MUST treat 3.3.3.3/32 as withdrawn even = though there was no explicit withdraw sent for it. That means, A doesn=92t= need to send an explicit withdraw for 3.3.3.3/32, and B must delete = 3.3.3.3/32=92s path from A. > =20 > This is the core semantics of BoRR and EoRR and it takes care of all = cases. This implies, e.g., if the sender A want to ensure that a = particular prefix, x.y.z.w/n, is not considered withdrawn by the = receiver, then A MUST advertise x.y.z.w/n following any BoRR (even in = nested cases) *before* any EoRR. > =20 > -----Original Message----- > From: Thomas Mangin [mailto:thomas.mangin@exa-networks.co.uk]=20 > Sent: Tuesday, January 28, 2014 11:50 PM > To: Saikat Ray (sairay) > Cc: Susan Hares; Jeff Tantsura; Keyur Patel (keyupate); Jakob Heitz; = idr-bounces@ietf.org; idr@ietf.org > Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh > =20 > Hello Saikat, > =20 > Why "both by the sender", if the route was not announced it is clearly = withdrawn on the sender side and by definition if a route is not in the = RR it has to be withdrawn - that said saying it can not harm .. > =20 > Thomas > =20 > Sent from my iPad > =20 > > On 29 Jan 2014, at 01:03, "Saikat Ray \(sairay\)" = wrote: > > > > The draft should add a line mandating the actual semantics (instead = of/in addition to the procedures of mark-and-sweep). Something along the = line: > > > > "Any route for which no update has been sent between a BoRR and the = following EoRR MUST be considered withdrawn by both the sender and the = receiver." > > > > The rest is really implementation (how to handle nested BoRR/EoRR or = GR EoR, etc.), IMHO. > > > > I support the draft, BTW. > > > > -----Original Message----- > > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares > > Sent: Tuesday, January 28, 2014 4:53 PM > > To: 'Jeff Tantsura'; Keyur Patel (keyupate); 'Jakob Heitz'; 'Thomas > > Mangin'; idr-bounces@ietf.org > > Cc: idr@ietf.org > > Subject: Re: [Idr] WG LC for = draft-ietf-idr-bgp-enhanced-route-refresh > > > > Any other comments? (support/discussion accepted) > > > > Sue Hares > > > > PS - Keyur - spin a draft with this change and end it to me. > > > > -----Original Message----- > > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jeff Tantsura > > Sent: Tuesday, January 28, 2014 5:56 PM > > To: Keyur Patel (keyupate); Jakob Heitz; Thomas Mangin; > > idr-bounces@ietf.org > > Cc: idr@ietf.org > > Subject: Re: [Idr] WG LC for = draft-ietf-idr-bgp-enhanced-route-refresh > > > > I support the wording below. > > > > Cheers, > > Jeff > > > > > > -----Original Message----- > > From: "keyupate@cisco.com" > > Date: Tuesday, January 28, 2014 1:43 PM > > To: "keyupate@cisco.com" , Jakob Heitz = , Thomas Mangin = , "idr-bounces@ietf.org" > > > > Cc: "idr@ietf.org" > > Subject: Re: [Idr] WG LC for = draft-ietf-idr-bgp-enhanced-route-refresh > > > >> Hi Jakob, > >> > >> How about the following (based on your suggestion): > >> > >> For a BGP speaker that supports the BGP Graceful Restart specified = in > >> [RFC4724] , it MUST NOT send a BoRR for an AFI/SAFI to a neighbor > >> before it sends the EOR for the AFI/SAFI to the neighbor. This > >> procedure would help the neighbor avoid the premature cleanup of > >> stale routes. > >> > >> > >> This would help simplify receiver side implementation wrt GR and > >> Enhanced RR. :) > >> > >> Regards, > >> Keyur > >> > >>> On 1/28/14 1:08 PM, "Keyur Patel (keyupate)" = wrote: > >>> > >>> Sure! I am saying you can simplify the implementation by simply > >>> delaying the servicing of the route refresh reply till the > >>> generation of > > an EOR. > >>> > >>> Question is do we allow the text to be flexible enough to cover = the > >>> other case. :) > >>> > >>> Regards, > >>> Keyur > >>> > >>>> On 1/28/14 12:56 PM, "Jakob Heitz" = wrote: > >>>> > >>>> Could we please simplify this a bit, not to force implementations > >>>> to use different stale bits? > >>>> > >>>> Thanks, > >>>> Jakob. > >>>> > >>>> -----Original Message----- > >>>> From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] > >>>> Sent: Tuesday, January 28, 2014 12:49 PM > >>>> To: Jakob Heitz; Thomas Mangin; idr-bounces@ietf.org > >>>> Cc: idr@ietf.org > >>>> Subject: Re: [Idr] WG LC for > >>>> draft-ietf-idr-bgp-enhanced-route-refresh > >>>> > >>>> > >>>> > >>>>> On 1/28/14 12:23 PM, "Jakob Heitz" = wrote: > >>>>> > >>>>> the order BoRR, EoR, EoRR allows this possible scenario: > >>>>> > >>>>> Suppose 2 routes exist :1.1.1.1/32, 2.2.2.2/32 The order could = now be: > >>>>> . start session > >>>>> . send 1.1.1.1/32 > >>>>> . receive route refresh request. > >>>>> . send BoRR > >>>>> . send 2.2.2.2/32 > >>>>> . send EoR > >>>>> . send 1.1.1.1/32 > >>>>> . send EoRR > >>>>> > >>>>> On receipt of EoR, the receiver could delete stales, deleting > >>>>> 1.1.1.1/32. > >>>> > >>>> Not if you use different flags/bits to mark them stale? > >>>> > >>>> Implementations could choose to always postpone the route refresh > >>>> reply and get the same behavior? > >>>> > >>>> Regards, > >>>> Keyur > >>>> > >>>>> > >>>>> Thanks, > >>>>> Jakob. > >>>>> > >>>>> -----Original Message----- > >>>>> From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] > >>>>> Sent: Tuesday, January 28, 2014 12:17 PM > >>>>> To: Jakob Heitz; Thomas Mangin; idr-bounces@ietf.org > >>>>> Cc: idr@ietf.org > >>>>> Subject: Re: [Idr] WG LC for > >>>>> draft-ietf-idr-bgp-enhanced-route-refresh > >>>>> > >>>>> The order: BoRR, EoR, EoRR lets an implementation do both, = merge > >>>>> route refresh reply with an initial table announcement or delay > >>>>> the route refresh replies. As long as EoR is sent before EoRR > >>>>> there should be no issue right? > >>>>> > >>>>> Regards, > >>>>> Keyur > >>>>>> On 1/28/14 12:06 PM, "Jakob Heitz" = wrote: > >>>>>> > >>>>>> Enke's text allows the order: BoRR, EoR, EoRR. > >>>>>> > >>>>>> Could we change Enke's text from > >>>>>> "it MUST NOT send an EoRR" to > >>>>>> "it MUST NOT send an BoRR" > >>>>>> > >>>>>> Thanks, > >>>>>> Jakob. > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Keyur = Patel > >>>>>> (keyupate) > >>>>>> Sent: Tuesday, January 28, 2014 11:51 AM > >>>>>> To: Thomas Mangin; idr-bounces@ietf.org > >>>>>> Cc: idr@ietf.org > >>>>>> Subject: Re: [Idr] WG LC for > >>>>>> draft-ietf-idr-bgp-enhanced-route-refresh > >>>>>> > >>>>>> Hi Jacob, Thomas, > >>>>>> > >>>>>> Am ok with implementations delaying the servicing of route > >>>>>> refresh request. Enke's suggested text addresses the concern. > >>>>>> > >>>>>> Best Regards, > >>>>>> Keyur > >>>>>> > >>>>>> On 1/26/14 3:39 PM, "Thomas Mangin" > >>>>>> > >>>>>> wrote: > >>>>>> > >>>>>>> Damn, time to practice then :) > >>>>>>> > >>>>>>> Joke apart, I agree with this post. The feature should not be > >>>>>>> used ( and ignored ) until the initial route exchange has been = completed. > >>>>>>> > >>>>>>> If the session drops, I would expect the router to cancel any = RR > >>>>>>> which was ongoing as the AdjRIBOut is going to be = retransmitted > >>>>>>> anyway. > >>>>>>> > >>>>>>> Thomas > >>>>>>> > >>>>>>> Sent from my iPad > >>>>>>> > >>>>>>>> On 25 Jan 2014, at 19:48, Jakob Heitz > >>>>>>>> > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>> RFCs are written for coders "practiced" in the art". > >>>>>>>> If anyone sends an EoRR before the adj-RIB-out is fully > >>>>>>>> populated, then it's a BUG. > >>>>>>>> This does not need to be said. > >>>>>>>> > >>>>>>>> Personally, I believe a route refresh request should not be > >>>>>>>> honored until GR is complete. > >>>>>>>> Also, I don't believe a timer for the receipt of EoRR is > >>>>>>>> necessary, because the EoRR is guaranteed. > >>>>>>>> Guaranteed means "unless the session drops first". > >>>>>>>> -- > >>>>>>>> > >>>>>>>> Jakob Heitz. > >>>>>>>> > >>>>>>>> ________________________________________ > >>>>>>>> From: Chris Hall [chris.hall@highwayman.com] > >>>>>>>> Sent: Saturday, 25 January 2014 11:27 AM > >>>>>>>> To: idr@ietf.org > >>>>>>>> Cc: Jakob Heitz > >>>>>>>> Subject: RE: [Idr] WG LC for > >>>>>>>> draft-ietf-idr-bgp-enhanced-route-refresh > >>>>>>>> > >>>>>>>> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): > >>>>>>>> ... > >>>>>>>>> Silence means don't do it. > >>>>>>>> > >>>>>>>> Hmmm.... as a principle I'm more comfortable with "that which > >>>>>>>> isn't prohibited is permitted".... > >>>>>>>> > >>>>>>>>> You would definitely NOT want BoRR to flush old stales. > >>>>>>>> > >>>>>>>> ....but, given the definite requirement, and given that the > >>>>>>>> current precedent for "marking stale" does flush old stale, > >>>>>>>> then a few words for the avoidance of doubt ? > >>>>>>>> > >>>>>>>>> Restarting the timer might be a good idea. > >>>>>>>> > >>>>>>>> I dunno... a route which remains stale for "a long time" is, = of > >>>>>>>> course, a candidate for being withdrawn: so having started a > >>>>>>>> timer the first time things are set stale, I would avoid > >>>>>>>> extending that > >>>>>>>> -- at least for Graceful Restart, where the whole withdraw > >>>>>>>> thing has been "on-hold" since the last session failed. For > >>>>>>>> route-refresh I guess there's more of a presumption that = stale > >>>>>>>> routes will be refreshed sooner or later, and in the meantime > >>>>>>>> they remain good. So if the route-refresh is (repeatedly) > >>>>>>>> restarted for some reason, perhaps it is more reasonable to > >>>>>>>> extend the flush deadline -- but avoid doing this = indefinitely ? > >>>>>>>> > >>>>>>>> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics = I > >>>>>>>> have built in Quagga prioritise route changes (pending = changes > >>>>>>>> and any that occur during the refresh) over refresh updates. > >>>>>>>> This makes it more likely that remaining stale routes are = still > > good. > >>>>>>>> But the other end cannot know that. > >>>>>>>> > >>>>>>>> The paragraph in the draft discussing the "entire = Adj-RIB-Out" > >>>>>>>> defines that to be the entries present "at the start of the > >>>>>>>> route refresh operation", and observes that these comprise = both > >>>>>>>> reachable and unreachable routes. [An "of" after "comprise" > >>>>>>>> sets teeth on edge, BTW.] I'm really not sure what this > >>>>>>>> paragraph is trying to tell me. > >>>>>>>> The reference to unreachable routes appears to suggest that > >>>>>>>> pending withdraws should be sent as part of the refresh -- so > >>>>>>>> not left to the EoRR to implement at the end. The point at > >>>>>>>> which the EoRR is sent is defined such that it excludes any > >>>>>>>> Adj-RIB-Out entries added after the route-refresh started, = but > >>>>>>>> includes any which are changed during the process. It seems > >>>>>>>> reasonable to delay any brand new reachable prefixes until > >>>>>>>> after all previously announced ones have been refreshed and = the > >>>>>>>> EoRR sent -- if that's the > > intent here. > >>>>>>>> Changes which occur before the refresh gets to a given entry > >>>>>>>> are pretty naturally swept up by the refresh. Changes which > >>>>>>>> occur after the refresh has gone past, could/should be = deferred > >>>>>>>> to after the EoRR ? > >>>>>>>> Does it make a difference if the change is a withdraw ? (Of > >>>>>>>> course MRAI may kick in here. Ah. MRAI and route-refresh, > >>>>>>>> there's a topic > >>>>>>>> !) > >>>>>>>> > >>>>>>>> I think the essence of the rule is that the EoRR should be = sent > >>>>>>>> once all prefixes previously advertised to the peer as > >>>>>>>> reachable have been refreshed, ie announced or withdrawn (at = least) once. > >>>>>>>> Or, perhaps more strictly, not *before* those prefixes have > >>>>>>>> *all* been announced once -- given that the EoRR will = promptly > >>>>>>>> bang un-advertised stuff on the head. Even more strictly > >>>>>>>> perhaps: not send EoRR *before* any withdraws implied by it = are > >>>>>>>> required or desirable. > >>>>>>>> > >>>>>>>> Depending on the implementation, a given sender may or may = not > >>>>>>>> be able to determine the minimum set of updates required = before > >>>>>>>> sending EoRR. > >>>>>>>> > >>>>>>>> If the refresh operation takes a long time, there may be good > >>>>>>>> routeing reasons to arrange for some route changes to be sent > >>>>>>>> to the peer "early" -- that is to send announcements which do > >>>>>>>> not contribute to the refresh, but which are important enough > >>>>>>>> to warrant delaying the end of the refresh. That could be a > >>>>>>>> matter for > >>>>>>>> recommendation(s) in the standard. > >>>>>>>> > >>>>>>>> NB: given that the timing of the EoRR is tied to the state of > >>>>>>>> the Adj-RIB-Out, I'm not sure about the Graceful Restart > > assumptions. > >>>>>>>> At the beginning of the initial update, the Restarting and > >>>>>>>> Receiving speakers have: > >>>>>>>> > >>>>>>>> Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out > >>>>>>>> > >>>>>>>> Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In > >>>>>>>> > >>>>>>>> Now suppose (bonkers or otherwise) the receiving speaker = sends > >>>>>>>> an RRQ part way through the initial update. The restarting > >>>>>>>> speaker responds with BoRR, everything in its Adj-RIB-Out, = and > >>>>>>>> EoRR -- per specification. The receiving speaker sees the > >>>>>>>> EoRR, and flushes stale. Unfortunately, if the restarting > >>>>>>>> speaker has not yet fully populated its Adj-RIB-Out, then = many > >>>>>>>> further routes will be sent before the EoR falls due -- but = the > >>>>>>>> receiving speaker has already flushed their tiny posteriors = :-( > >>>>>>>> > >>>>>>>> I am coming to the view that route-refresh during a Graceful > >>>>>>>> Restart initial update is a horse of a different colour = altogether. > >>>>>>>> > >>>>>>>> [So the assumption that EoRR and EoR are triggered by the = same > >>>>>>>> thing was completely wrong, and I apologise for it.] > >>>>>>>> > >>>>>>>> Chris > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> 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 > >> > >> _______________________________________________ > >> 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 > > --Apple-Mail=_7F0681F1-6802-491D-831B-DA99F342BAD3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hello = Sairay,

Thank you for taking the time to put this = flow together. Appreciated. This is how I understood the router = behaviour too. What I was questioning was the need to have the word = "sender" in the sentence.

The following wording = should cover this case IMHO :

"Any route for = which no update has been sent between a BoRR and the following EoRR MUST = be considered withdrawn by the receiver" or even = shorter
"Any route for which no update has been sent = between a BoRR and the following EoRR MUST be considered = withdrawn"

I was trying to understand why = you felt the need to specify the sender, where the route is already = withdrawn as the RR did not contain it = ...

Thomas

On 30 Jan = 2014, at 01:38, Saikat Ray (sairay) <sairay@cisco.com> = wrote:

The route may have = been advertised before (and not (yet) withdrawn). Consider the = example:
 
+---+     +---+
| A = +-----+ B |
+---+     = +---+
 
t=3D0: A sends three prefixes: 1.1.1.1/32, = 2.2.2.2/32, 3.3.3.3/32, to B.
t=3D1: = B sends an (enhanced) route-refresh request to A.
t=3D2: A sends BoRR to B.
t=3D3: A sends 1.1.1.1/32 and 2.2.2.2/32 to = B
t=3D4: A sends EoRR to = B.
 
At this point, both A and B MUST treat 3.3.3.3/32 = as withdrawn even though there was no explicit withdraw sent for it. = That means, A doesn=92t need to send an explicit withdraw for = 3.3.3.3/32, and B must delete 3.3.3.3/32=92s path from = A.
 
This is the core semantics of BoRR and EoRR and it = takes care of all cases. This implies, e.g., if the sender A want to = ensure that a particular prefix, x.y.z.w/n, is not considered withdrawn = by the receiver, then A MUST advertise x.y.z.w/n following any BoRR = (even in nested cases) *before* any EoRR.
 
-----Original Message-----
From: Thomas Mangin [mailto:thomas.mangin@exa-= networks.co.uk] 
Sent: Tuesday, January = 28, 2014 11:50 PM
To: Saikat Ray (sairay)
Cc: Susan Hares; Jeff = Tantsura; Keyur Patel (keyupate); Jakob Heitz; idr-bounces@ietf.org; idr@ietf.org
Subject: Re: [Idr] WG = LC for draft-ietf-idr-bgp-enhanced-route-refresh
 
Hello = Saikat,
 
Why "both = by the sender", if the route was not announced it is clearly withdrawn = on the sender side and by definition if a route is not in the RR it has = to be withdrawn - that said saying it can not harm = ..
 
Thomas
 
Sent from = my iPad
 
> On 29 = Jan 2014, at 01:03, "Saikat Ray \(sairay\)" <sairay@cisco.com> = wrote:
>
> The = draft should add a line mandating the actual semantics (instead of/in = addition to the procedures of mark-and-sweep). Something along the = line:
>
> "Any route for which no update has been sent = between a BoRR and the following EoRR MUST be considered withdrawn by = both the sender and the receiver."
>
> The = rest is really implementation (how to handle nested BoRR/EoRR or GR EoR, = etc.), IMHO.
>
> I = support the draft, BTW.
>
> = -----Original Message-----
> From: = Idr [mailto:idr-bounces@ietf.org] On = Behalf Of Susan Hares
> Sent: = Tuesday, January 28, 2014 4:53 PM
> To: 'Jeff Tantsura'; Keyur Patel (keyupate); 'Jakob = Heitz'; 'Thomas
> = Subject: Re: [Idr] WG LC for = draft-ietf-idr-bgp-enhanced-route-refresh
>
> Any = other comments?  (support/discussion accepted)
>
> Sue = Hares
>
> PS - Keyur - spin a draft with this change = and end it to me.
>
> = -----Original Message-----
> From: = Idr [mailto:idr-bounces@ietf.org] On = Behalf Of Jeff Tantsura
> Sent: = Tuesday, January 28, 2014 5:56 PM
> To: Keyur Patel (keyupate); Jakob Heitz; Thomas = Mangin;
> = Subject: Re: [Idr] WG LC for = draft-ietf-idr-bgp-enhanced-route-refresh
>
> I = support the wording below.
>
> = Cheers,
> = Jeff
>
>
> = -----Original Message-----
> Date: Tuesday, January 28, 2014 1:43 = PM
> Subject: Re: [Idr] WG LC for = draft-ietf-idr-bgp-enhanced-route-refresh
>
>> = Hi Jakob,
>>
>> = How about the following (based on your suggestion):
>>
>> For a BGP speaker that supports the BGP Graceful = Restart specified in
>> = [RFC4724] , it MUST NOT send a BoRR for an AFI/SAFI to a = neighbor
>> before it = sends the EOR for the AFI/SAFI to the neighbor.  = This
>> procedure would help = the neighbor avoid the premature cleanup of
>> stale routes.
>>
>>
>> = This would help simplify receiver side implementation wrt GR = and
>> Enhanced RR. = :)
>>
>> Regards,
>> Keyur
>>
>>> On 1/28/14 1:08 PM, "Keyur Patel (keyupate)" = <keyupate@cisco.com> = wrote:
>>>
>>> Sure! I am saying you can simplify the = implementation by simply
>>> delaying the servicing of the route refresh = reply till the
>>> = generation of
> an = EOR.
>>>
>>> Question is do we allow the text to be = flexible enough to cover the
>>> other case. :)
>>>
>>> Regards,
>>> Keyur
>>>
>>>> On 1/28/14 12:56 PM, "Jakob Heitz" <jakob.heitz@ericsson.com> = wrote:
>>>>
>>>> Could we please simplify this a bit, not = to force implementations
>>>> to use different stale = bits?
>>>>
>>>> Thanks,
>>>> Jakob.
>>>>
>>>> -----Original = Message-----
>>>> = From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com]
>>>> Sent: Tuesday, January 28, 2014 = 12:49 PM
>>>> To: = Jakob Heitz; Thomas Mangin; idr-bounces@ietf.org
>>>> Cc: idr@ietf.org
>>>> Subject: Re: [Idr] WG LC = for
>>>> = draft-ietf-idr-bgp-enhanced-route-refresh
>>>>
>>>>
>>>>
>>>>> On 1/28/14 12:23 PM, "Jakob = Heitz" <jakob.heitz@ericsson.com> = wrote:
>>>>>
>>>>> the order BoRR, EoR, EoRR allows this = possible scenario:
>>>>>
>>>>> Suppose 2 routes exist :1.1.1.1/32, = 2.2.2.2/32 The order could now be:
>>>>> . start session
>>>>> . send = 1.1.1.1/32
>>>>> = . receive route refresh request.
>>>>> . send BoRR
>>>>> . send = 2.2.2.2/32
>>>>> = . send EoR
>>>>> = . send 1.1.1.1/32
>>>>> . send EoRR
>>>>>
>>>>> On receipt of EoR, the = receiver could delete stales, deleting
>>>>> = 1.1.1.1/32.
>>>>
>>>> Not if you use different flags/bits to = mark them stale?
>>>>
>>>> Implementations could choose to always = postpone the route refresh
>>>> reply and get the same = behavior?
>>>>
>>>> Regards,
>>>> Keyur
>>>>
>>>>>
>>>>> Thanks,
>>>>> Jakob.
>>>>>
>>>>> -----Original = Message-----
>>>>> = From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com]
>>>>> Sent: Tuesday, January 28, = 2014 12:17 PM
>>>>> = To: Jakob Heitz; Thomas Mangin; idr-bounces@ietf.org
>>>>> Cc: idr@ietf.org
>>>>> Subject: Re: [Idr] WG LC = for
>>>>> = draft-ietf-idr-bgp-enhanced-route-refresh
>>>>>
>>>>> The order: BoRR, EoR, EoRR = lets an implementation do both,  merge
>>>>> route refresh reply with an = initial table announcement or delay
>>>>> the route refresh replies. As long as = EoR is sent before EoRR
>>>>> there should be no issue = right?
>>>>>
>>>>> Regards,
>>>>> Keyur
>>>>>> On 1/28/14 12:06 PM, = "Jakob Heitz" <jakob.heitz@ericsson.com> = wrote:
>>>>>>
>>>>>> Enke's text allows the = order: BoRR, EoR, EoRR.
>>>>>>
>>>>>> Could we change Enke's = text from
>>>>>> "it MUST NOT send an EoRR" = to
>>>>>> "it = MUST NOT send an BoRR"
>>>>>>
>>>>>> = Thanks,
>>>>>> Jakob.
>>>>>>
>>>>>> -----Original = Message-----
>>>>>> From: Idr [mailto:idr-bounces@ietf.org] On = Behalf Of Keyur Patel
>>>>>> (keyupate)
>>>>>> Sent: Tuesday, January = 28, 2014 11:51 AM
>>>>>> To: Thomas Mangin; idr-bounces@ietf.org
>>>>>> Cc: idr@ietf.org
>>>>>> Subject: Re: [Idr] WG LC = for
>>>>>> = draft-ietf-idr-bgp-enhanced-route-refresh
>>>>>>
>>>>>> Hi Jacob, = Thomas,
>>>>>>
>>>>>> Am ok with = implementations delaying the servicing of route
>>>>>> refresh request. Enke's = suggested text addresses the concern.
>>>>>>
>>>>>> Best = Regards,
>>>>>> Keyur
>>>>>>
>>>>>> On 1/26/14 3:39 PM, = "Thomas Mangin"
>>>>>> = wrote:
>>>>>>
>>>>>>> Damn, time to = practice then :)
>>>>>>>
>>>>>>> Joke apart, I agree = with this post. The feature should not be
>>>>>>> used ( and ignored ) = until the initial route exchange has been = completed.
>>>>>>>
>>>>>>> If the session drops, = I would expect the router to cancel any RR
>>>>>>> which was ongoing as = the AdjRIBOut is going to be retransmitted
>>>>>>> = anyway.
>>>>>>>
>>>>>>> = Thomas
>>>>>>>
>>>>>>> Sent from my = iPad
>>>>>>>
>>>>>>>> On 25 Jan 2014, = at 19:48, Jakob Heitz
>>>>>>>> = wrote:
>>>>>>>>
>>>>>>>> RFCs are written = for coders "practiced" in the art".
>>>>>>>> If anyone sends an EoRR = before the adj-RIB-out is fully
>>>>>>>> populated, then it's a = BUG.
>>>>>>>> This does not need to be = said.
>>>>>>>>
>>>>>>>> Personally, I = believe a route refresh request should not be
>>>>>>>> honored until GR = is complete.
>>>>>>>> Also, I don't believe a = timer for the receipt of EoRR is
>>>>>>>> necessary, because the = EoRR is guaranteed.
>>>>>>>> Guaranteed means "unless = the session drops first".
>>>>>>>> --
>>>>>>>>
>>>>>>>> Jakob = Heitz.
>>>>>>>>
>>>>>>>> = ________________________________________
>>>>>>>> From: Chris Hall = [chris.hall@highwayman.com]
>>>>>>>> = Sent: Saturday, 25 January 2014 11:27 AM
>>>>>>>> To: idr@ietf.org
>>>>>>>> Cc: Jakob = Heitz
>>>>>>>> Subject: RE: [Idr] WG LC = for
>>>>>>>> = draft-ietf-idr-bgp-enhanced-route-refresh
>>>>>>>>
>>>>>>>> Jakob Heitz wrote = (on Fri 24-Jan-2014 at 20:37):
>>>>>>>> ...
>>>>>>>>> Silence means = don't do it.
>>>>>>>>
>>>>>>>> Hmmm.... as a = principle I'm more comfortable with "that which
>>>>>>>> isn't prohibited = is permitted"....
>>>>>>>>
>>>>>>>>> You would = definitely NOT want BoRR to flush old stales.
>>>>>>>>
>>>>>>>> ....but, given = the definite requirement, and given that the
>>>>>>>> current precedent = for "marking stale" does flush old stale,
>>>>>>>> then a few words = for the avoidance of doubt ?
>>>>>>>>
>>>>>>>>> Restarting = the timer might be a good idea.
>>>>>>>>
>>>>>>>> I dunno... a = route which remains stale for "a long time" is, of
>>>>>>>> course, a = candidate for being withdrawn: so having started a
>>>>>>>> timer the first = time things are set stale, I would avoid
>>>>>>>> extending = that
>>>>>>>> -- at least for Graceful = Restart, where the whole withdraw
>>>>>>>> thing has been "on-hold" = since the last session failed.  For
>>>>>>>> route-refresh I = guess there's more of a presumption that stale
>>>>>>>> routes will be = refreshed sooner or later, and in the meantime
>>>>>>>> they remain = good.  So if the route-refresh is (repeatedly)
>>>>>>>> restarted for = some reason, perhaps it is more reasonable to
>>>>>>>> extend the flush = deadline -- but avoid doing this indefinitely ?
>>>>>>>>
>>>>>>>> FWIW, for = route-refresh and for GR, the Adj-RIB-Out mechanics = I
>>>>>>>> have built in Quagga = prioritise route changes (pending changes
>>>>>>>> and any that = occur during the refresh) over refresh updates.
>>>>>>>> This makes it = more likely that remaining stale routes are still
> good.
>>>>>>>> But the other end cannot = know that.
>>>>>>>>
>>>>>>>> The paragraph in = the draft discussing the "entire Adj-RIB-Out"
>>>>>>>> defines that to = be the entries present "at the start of the
>>>>>>>> route refresh = operation", and observes that these comprise both
>>>>>>>> reachable and = unreachable routes.  [An "of" after "comprise"
>>>>>>>> sets teeth on = edge, BTW.]  I'm really not sure what this
>>>>>>>> paragraph is = trying to tell me.
>>>>>>>> The reference to = unreachable routes appears to suggest that
>>>>>>>> pending withdraws = should be sent as part of the refresh -- so
>>>>>>>> not left to the = EoRR to implement at the end.  The point at
>>>>>>>> which the EoRR is = sent is defined such that it excludes any
>>>>>>>> Adj-RIB-Out = entries added after the route-refresh started, but
>>>>>>>> includes any = which are changed during the process.  It = seems
>>>>>>>> reasonable to delay any = brand new reachable prefixes until
>>>>>>>> after all previously = announced ones have been refreshed and the
>>>>>>>> EoRR sent -- if = that's the
> intent = here.
>>>>>>>> Changes which occur before = the refresh gets to a given entry
>>>>>>>> are pretty naturally swept = up by the refresh.  Changes which
>>>>>>>> occur after the = refresh has gone past, could/should be deferred
>>>>>>>> to after the EoRR = ?
>>>>>>>> Does it make a difference = if the change is a withdraw ?  (Of
>>>>>>>> course MRAI may = kick in here.  Ah.  MRAI and = route-refresh,
>>>>>>>> there's a = topic
>>>>>>>> !)
>>>>>>>>
>>>>>>>> I think the = essence of the rule is that the EoRR should be sent
>>>>>>>> once  all = prefixes previously advertised to the peer as
>>>>>>>> reachable = have  been refreshed, ie announced or withdrawn (at least) = once.
>>>>>>>> Or,  perhaps more = strictly, not *before* those prefixes have
>>>>>>>> *all* been  = announced once -- given that the EoRR will promptly
>>>>>>>> bang = un-advertised stuff on the head.  Even more = strictly
>>>>>>>> perhaps: not send EoRR = *before* any withdraws implied by it are
>>>>>>>> required or = desirable.
>>>>>>>>
>>>>>>>> Depending on the = implementation, a given sender may or may not
>>>>>>>> be able to = determine the minimum set of updates required = before
>>>>>>>> sending = EoRR.
>>>>>>>>
>>>>>>>> If the refresh = operation takes a long time, there may be good
>>>>>>>> routeing reasons = to arrange for some route changes to be sent
>>>>>>>> to the peer = "early" -- that is to send announcements which do
>>>>>>>> not contribute to = the refresh, but which are important enough
>>>>>>>> to warrant = delaying the end of the refresh.  That could be = a
>>>>>>>> matter = for
>>>>>>>> recommendation(s) in the = standard.
>>>>>>>>
>>>>>>>> NB: given that = the timing of the EoRR is tied to the state of
>>>>>>>> the Adj-RIB-Out, = I'm not sure about the Graceful Restart
> assumptions.
>>>>>>>> At the beginning = of the initial update, the Restarting and
>>>>>>>> Receiving = speakers have:
>>>>>>>>
>>>>>>>> Restarting:  = Empty Adj-RIB-In   Empty Adj-RIB-Out
>>>>>>>>
>>>>>>>> = Receiving:   Empty Adj-RIB-Out  Stale = Adj-RIB-In
>>>>>>>>
>>>>>>>> Now suppose = (bonkers or otherwise) the receiving speaker sends
>>>>>>>> an RRQ part way = through the initial update.  The restarting
>>>>>>>> speaker responds = with BoRR, everything in its Adj-RIB-Out, and
>>>>>>>> EoRR -- per = specification.  The receiving speaker sees the
>>>>>>>> EoRR, and flushes = stale.  Unfortunately, if the restarting
>>>>>>>> speaker has not = yet fully populated its Adj-RIB-Out, then many
>>>>>>>> further routes = will be sent before the EoR falls due -- but the
>>>>>>>> receiving speaker = has already flushed their tiny posteriors :-(
>>>>>>>>
>>>>>>>> I am coming to = the view that route-refresh during a Graceful
>>>>>>>> Restart initial = update is a horse of a different colour altogether.
>>>>>>>>
>>>>>>>> [So the = assumption that EoRR and EoR are triggered by the = same
>>>>>>>> thing was completely = wrong, and I apologise for it.]
>>>>>>>>
>>>>>>>> = Chris
>>>>>>>>
>>>>>>>> = _______________________________________________
>>>>>>>> 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
>>> https://www.ietf.org/mailman/listinfo/idr
>>
>> = _______________________________________________
>> Idr mailing list
>> https://www.ietf.org/mailman/listinfo/idr
>
> = _______________________________________________
> Idr mailing list
> https://www.ietf.org/mailman/listinfo/idr
>
> = _______________________________________________
> Idr mailing list

= --Apple-Mail=_7F0681F1-6802-491D-831B-DA99F342BAD3-- --Apple-Mail=_837DCAB4-CC25-4FDF-A030-81E2A962E82C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlLp/sUACgkQA/52wvuLgaHYowCgw6h48PnFiFJyYximnt0AycP8 6/IAoJuROvZCPt2C7ZbqtRxnISzNCZNT =NxIA -----END PGP SIGNATURE----- --Apple-Mail=_837DCAB4-CC25-4FDF-A030-81E2A962E82C-- From bruno.decraene@orange.com Thu Jan 30 02:28:09 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6581A0448 for ; Thu, 30 Jan 2014 02:28:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jR_d-jv8ukoi for ; Thu, 30 Jan 2014 02:28:02 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 6D26C1A042C for ; Thu, 30 Jan 2014 02:28:01 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 6536F374225; Thu, 30 Jan 2014 11:27:57 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 4C7C7384081; Thu, 30 Jan 2014 11:27:57 +0100 (CET) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Thu, 30 Jan 2014 11:27:57 +0100 From: To: "Keyur Patel (keyupate)" Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPHT+x3MXmo8KxoESEhujQiGLM/ZqdC/SA Date: Thu, 30 Jan 2014 10:27:56 +0000 Message-ID: <22670_1391077677_52EA292D_22670_18044_1_53C29892C857584299CBF5D05346208A070E0357@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <6650_1390989061_52E8CF05_6650_399_1_53C29892C857584299CBF5D05346208A070DFED8@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A070E0357PEXCVZYM11corpo_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.30.93615 Cc: "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 10:28:09 -0000 --_000_53C29892C857584299CBF5D05346208A070E0357PEXCVZYM11corpo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Keyur, Thanks for your reply. Your proposed new text, using NOTIFICATION only for syntax errors seems muc= h better to me. Thanks for the clarification. Ideally, in addition, I would prefer to have a text also covering other typ= es of errors. At least the violation of explicit statement in the draft. E.= g. for the following 2 MUST " Before the speaker starts a route refresh that is either initiated locally, or in response to a "normal route refresh request" from the peer, the speaker MUST send a BoRR message. After the speaker completes the re-advertisement of the entire Adj-RIB-Out to the peer, it MUST send an EoRR message." Regarding the first one, IMHO there is no harm if the MUST is not enforced.= One option may be :s/MUST/SHOULD; or a statement in =A7 "Error handling" o= n how to handle this error (e.g. log and nothing else). Regarding the second one, I'd like to see a text specifying what should be = done when I receive two BoRR. E.g. -a- consider that the second BoRR should be considered as a EoRR+ BoRR -b- ignore/abort the first EoRR procedure (i.e. remark all routes as STALE = when the second EoRR is received) -c- ignore the second EoRR. (plus obviously log the error in all cases) "a" sounds dangerous to me. "b" should a priori ok (accept a small error but consider that the speaker = remember (and acted as per) its latest message.) "c" is the safest path (there is a error, I don't know what it is so I take= the safest option) Considering the motivation for this draft (enhance BGP robustness, but not = bring a new feature), I think I would prefer "c" which is the more robust. = Especially given that if the receiver has a doubt, I has a way to clear it = by sending a new Route Refresh message. But I guess I would be fine with "b" if you/the WG have a different opinion. (My understanding of the current draft, is that "b" is expected, but in all= cases I would prefer a specific text in =A7 "Error handling") Thanks, Cheers, Bruno From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] Sent: Wednesday, January 29, 2014 11:16 PM To: DECRAENE Bruno IMT/OLN; Robert Raszuk Cc: idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Bruno, We only generate Notification for invalid length. Apologies for the confusi= on. Attached is the revised text. Regards, Keyur The error handling specified in this section is applicable only when a BGP speaker has received the "Enhanced Route Refresh Capability" from a peer. If the length, excluding the fixed-size message header, of the received ROUTE-REFRESH message with Message Subtype 1 and 2 is not 4, then the BGP speaker MUST send a NOTIFICATION message with the Error Code of "ROUTE-REFRESH Message Error" and the subcode of "Invalid Message Length". The Data field of the NOTIFICATION message MUST contain the complete ROUTE-REFRESH message. When the BGP speaker receives a ROUTE-REFRESH message with a "Message Subtype" field other than 1 or 2, it MUST ignore the received ROUTE- REFRESH message. It SHOULD log an error for further analysis. From: > Date: Wed, 29 Jan 2014 09:51:00 +0000 To: Robert Raszuk >, Keyur Pate= l > Cc: "idr@ietf.org" > Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi all, From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: Wednesday, January 29, 2014 10:15 AM To: Dongjie (Jimmy) Cc: Keyur Patel (keyupate); idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Jimmy and all, I think Enke and Keyur's proposed text with help from Jakob makes the behav= ior simplified and deterministic to hold on BoRR till first EoR is seen. IMHO it should be also spelled out what is the expected sequence error hand= ling here [Bruno] +1. And taking into account possible interaction with draft-ietf-i= dr-bgp-gr-notification BTW: "When the BGP speaker detects an error while processing a ROUTE-REFRESH mes= sage with a non-zero "Message Subtype" field, it MUST send a NOTIFICATION m= essage with Error Code "ROUTE-REFRESH Message Error"." Seems a priori not inline with the recommendation from draft-ietf-grow-ops-= reqs-for-bgp-error-handling (which is to limit the consequences of error ha= ndling). Are we sure that no error condition could be handled in a more fri= endly way? (e.g. if BoRR is not sent following a "normal route refresh requ= est" or if 2 BoRR are sent consecutively...) Thanks, Regards, Bruno ... I think not following "MUST NOT" shall implicitly result in entire sess= ion drop and complete restart ? Any error code ? Best, R. On Wed, Jan 29, 2014 at 9:22 AM, Dongjie (Jimmy) > wrote: Hi Robert, Agree that in these cases the RRQ cannot be ignored, so postpone may be a b= etter choice. While IMO stop the initial update and start over may delay the initial conv= ergence, and as you said it also relates to update group processing. What = do you think about the new text provided by Keyur? Best regards, Jie From:rraszuk@gmail.com [mailto:rraszuk@gmail.com<= mailto:rraszuk@gmail.com>] On Behalf Of Robert Raszuk Sent: Sunday, January 26, 2014 11:03 PM To: Dongjie (Jimmy) Cc: Keyur Patel (keyupate); Jakob Heitz; idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Jie, I think it actually very easy to say that initial update can not ever guara= ntee that RRQ received during its sending may meet the peer's need. Example 1: SAFI 128 - During receiving initial update from RR to PE new VRF got added = with new RT import. Unfortunately those updates received within initial upd= ate were already dropped as not interesting by the PE. RR must resend full = table after completed initial update. (Of course this is the case where the= re is no RTC and that's why RTC helps a lot here by incremental nature). Example 2: SAFI 1 - Operator has modified inbound policy on EBGP peer during processin= g of incoming updates and those originally were dropped. No soft reconfig i= n set. Conclusion: RRQ can not ever be ignored. Sure they can be delayed or batched (case of m= ultiple peers within the same update/peer group) sending near RRQs (cluster= of PEs got provisioned from central management station). But as Keyur alre= ady mentioned those are rather standard local implementation optimizations. Question: Does it maybe make sense to stop initial update when receiving RRQ from a p= eer and start over ? Of course if peer is part of large update group it wou= ld have to be removed dynamically from it so other members are not delayed.= In any case I think this does not impact the spec but the implementation. Cheers, R. On Sun, Jan 26, 2014 at 7:13 PM, Dongjie (Jimmy) > wrote: Hi Keyur, Jakob, Agree that "postpone" may be better. The point is we could avoid the compli= cated cases/considerations of performing route refresh during initial updat= e:) For "ignore", I was thinking of scenarios in which the route refresh requir= ement may already be met by the initial update, while I'd admit it is hard = to say... Best regards, Jie -----Original Message----- From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] Sent: Sunday, January 26, 2014 8:30 PM To: Jakob Heitz; Dongjie (Jimmy) Cc: idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Jie, I agree with Jakob. You could make it *an implementation behavior* to postp= one the route refresh reply. Regards, Keyur On 1/26/14 1:29 AM, "Jakob Heitz" > wrote: >You can definitely not ignore it, but you could postpone it. > >-- >Jakob Heitz. > >> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" > >>wrote: >> >> After reading the analyses in this thread, my personal feeling is >>maybe we should avoid the interleaving between GR initial update and >>route refresh/enhanced route refresh, since the initial update is just >>sending the whole Adj-RIB-Out, there is no obvious advantage to start >>a route refresh/enhance route refresh during it. So a speaker should >>ignore the RRQ received during the initial update. Thoughts? >> >> Best regards, >> Jie >> >> -----Original Message----- >> From: Idr [mailto:idr-bounces@ietf.org] On = Behalf Of Jakob Heitz >> Sent: Saturday, January 25, 2014 10:48 PM >> To: Chris Hall; idr@ietf.org >> Subject: Re: [Idr] WG LC for >> draft-ietf-idr-bgp-enhanced-route-refresh >> >> RFCs are written for coders "practiced" in the art". >> If anyone sends an EoRR before the adj-RIB-out is fully populated, >>then it's a BUG. >> This does not need to be said. >> >> Personally, I believe a route refresh request should not be honored >>until GR is complete. >> Also, I don't believe a timer for the receipt of EoRR is necessary, >>because the EoRR is guaranteed. >> Guaranteed means "unless the session drops first". >> -- >> >> Jakob Heitz. >> >> ________________________________________ >> From: Chris Hall [chris.hall@highwayman.com] >> Sent: Saturday, 25 January 2014 11:27 AM >> To: idr@ietf.org >> Cc: Jakob Heitz >> Subject: RE: [Idr] WG LC for >> draft-ietf-idr-bgp-enhanced-route-refresh >> >> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): >> ... >>> Silence means don't do it. >> >> Hmmm.... as a principle I'm more comfortable with "that which isn't >>prohibited is permitted".... >> >>> You would definitely NOT want BoRR to flush old stales. >> >> ....but, given the definite requirement, and given that the current >>precedent for "marking stale" does flush old stale, then a few words >>for the avoidance of doubt ? >> >>> Restarting the timer might be a good idea. >> >> I dunno... a route which remains stale for "a long time" is, of >>course, a candidate for being withdrawn: so having started a timer the >>first time things are set stale, I would avoid extending that -- at >>least for Graceful Restart, where the whole withdraw thing has been "on-h= old" >>since the last session failed. For route-refresh I guess there's more >>of a presumption that stale routes will be refreshed sooner or later, >>and in the meantime they remain good. So if the route-refresh is >>(repeatedly) restarted for some reason, perhaps it is more reasonable >>to extend the flush deadline -- but avoid doing this indefinitely ? >> >> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I have >>built in Quagga prioritise route changes (pending changes and any that >>occur during the refresh) over refresh updates. This makes it more >>likely that remaining stale routes are still good. But the other end >>cannot know that. >> >> The paragraph in the draft discussing the "entire Adj-RIB-Out" >>defines that to be the entries present "at the start of the route >>refresh operation", and observes that these comprise both reachable >>and unreachable routes. [An "of" after "comprise" sets teeth on edge, >>BTW.] I'm really not sure what this paragraph is trying to tell me. >> The reference to unreachable routes appears to suggest that pending >>withdraws should be sent as part of the refresh -- so not left to the >>EoRR to implement at the end. The point at which the EoRR is sent is >>defined such that it excludes any Adj-RIB-Out entries added after the >>route-refresh started, but includes any which are changed during the >>process. It seems reasonable to delay any brand new reachable >>prefixes until after all previously announced ones have been refreshed >>and the EoRR sent -- if that's the intent here. Changes which occur >>before the refresh gets to a given entry are pretty naturally swept up >>by the refresh. Changes which occur after the refresh has gone past, >>could/should be deferred to after the EoRR ? Does it make a >>difference if the change is a withdraw ? (Of course MRAI may kick in her= e. Ah. >>MRAI and route-refresh, there's a topic !) >> >> I think the essence of the rule is that the EoRR should be sent once >>all prefixes previously advertised to the peer as reachable have been >>refreshed, ie announced or withdrawn (at least) once. Or, perhaps >>more strictly, not *before* those prefixes have *all* been announced >>once -- given that the EoRR will promptly bang un-advertised stuff on the= head. >>Even more strictly perhaps: not send EoRR *before* any withdraws >>implied by it are required or desirable. >> >> Depending on the implementation, a given sender may or may not be >>able to determine the minimum set of updates required before sending EoRR. >> >> If the refresh operation takes a long time, there may be good >>routeing reasons to arrange for some route changes to be sent to the peer= "early" >>-- that is to send announcements which do not contribute to the >>refresh, but which are important enough to warrant delaying the end of >>the refresh. That could be a matter for recommendation(s) in the standar= d. >> >> NB: given that the timing of the EoRR is tied to the state of the >>Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. At >>the beginning of the initial update, the Restarting and Receiving >>speakers have: >> >> Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out >> >> Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In >> >> Now suppose (bonkers or otherwise) the receiving speaker sends an RRQ >>part way through the initial update. The restarting speaker responds >>with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specification. >> The receiving speaker sees the EoRR, and flushes stale. >>Unfortunately, if the restarting speaker has not yet fully populated >>its Adj-RIB-Out, then many further routes will be sent before the EoR >>falls due -- but the receiving speaker has already flushed their tiny >>posteriors :-( >> >> I am coming to the view that route-refresh during a Graceful Restart >>initial update is a horse of a different colour altogether. >> >> [So the assumption that EoRR and EoR are triggered by the same thing >>was completely wrong, and I apologise for it.] >> >> Chris >> >> _______________________________________________ >> 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 ___________________________________________________________________________= ______________________________________________ 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, 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 authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ 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, 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 authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A070E0357PEXCVZYM11corpo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Keyur,<= o:p>

 = ;

Thanks for= your reply.

Your propo= sed new text, using NOTIFICATION only for syntax errors seems much better t= o me. Thanks for the clarification.

 = ;

Ideally, i= n addition, I would prefer to have a text also covering other types of erro= rs. At least the violation of explicit statement in the draft. E.g. for the following 2 MUST

“   Before the speaker star= ts a route refresh that is either initiated

   locally, or in response to a &= quot;normal route refresh request" from the

   peer, the speaker MUST send a B= oRR message.  After the speaker

   completes the re-advertisement= of the entire Adj-RIB-Out to the peer,

   it MUST send an = EoRR message.”

 = ;

Regarding = the first one, IMHO there is no harm if the MUST is not enforced. One optio= n may be :s/MUST/SHOULD; or a statement in =A7 “Error handling” on how to handle this error (e.g. log and nothing else).=

Regarding = the second one, I’d like to see a text specifying what should be done= when I receive two BoRR. E.g.

-a- consid= er that the second BoRR should be considered as a EoRR+ BoRR=

-b- ignore= /abort the first EoRR procedure (i.e. remark all routes as STALE when the s= econd EoRR is received)

-c- ignore= the second EoRR.

 = ;

(plus obvi= ously log the error in all cases)

 = ;

“a&#= 8221; sounds dangerous to me.

“b&#= 8221; should a priori ok (accept a small error but consider that the speake= r remember (and acted as per) its latest message.)

“c&#= 8221; is the safest path (there is a error, I don’t know what it is s= o I take the safest option)

 = ;

Considerin= g the motivation for this draft (enhance BGP robustness, but not bring a ne= w feature), I think I would prefer “c” which is the more robust. Especially given that if the receiver has a doubt, I has a way to clear it= by sending a new Route Refresh message.

But I gues= s I would be fine with “b” if you/the WG have a different opini= on.

(My unders= tanding of the current draft, is that “b” is expected, but in a= ll cases I would prefer a specific text in  =A7 “Error handling&= #8221;)

 = ;

Thanks,

Cheers,

Bruno=

 <= /p>

 <= /p>

From: Keyur Pa= tel (keyupate) [mailto:keyupate@cisco.com]
Sent: Wednesday, January 29, 2014 11:16 PM
To: DECRAENE Bruno IMT/OLN; Robert Raszuk
Cc: idr@ietf.org
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refre= sh

 

Hi Bruno,=

 

We only generate Notificati= on for invalid length. Apologies for the confusion. Attached is the revised= text.

 

Regards,<= /p>

Keyur

 

<snip>

The error handling specifie= d in this section is applicable only when

   a BGP speaker = has received the "Enhanced Route Refresh Capability"

   from a peer.

 

   If the length,= excluding the fixed-size message header, of the

   received ROUTE= -REFRESH message with Message Subtype 1 and 2 is not 4,

   then the BGP s= peaker MUST send a NOTIFICATION message with the Error

   Code of "= ROUTE-REFRESH Message Error" and the subcode of "Invalid

   Message Length= ".  The Data field of the NOTIFICATION message MUST

   contain the co= mplete ROUTE-REFRESH message.

 

   When the BGP s= peaker receives a ROUTE-REFRESH message with a "Message

   Subtype" = field other than 1 or 2, it MUST ignore the received ROUTE-

   REFRESH messag= e.  It SHOULD log an error for further analysis.

 

<snip>

 

From: <bruno.decraene@orange.com>
Date: Wed, 29 Jan 2014 09:51:00 +0000
To: Robert Raszuk <robert@ra= szuk.net>, Keyur Patel <key= upate@cisco.com>
Cc: "idr@ietf.org" <= ;idr@ietf.org>
Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refre= sh

 

Hi all,

 

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Wednesday, January 29, 2014 10:15 AM
To: Dongjie (Jimmy)
Cc: Keyur Patel (keyupate); idr@ietf= .org
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refre= sh

 

Hi Jimmy and all,=

 

I think Enke and Keyur's proposed text with help from Jakob mak= es the behavior simplified and deterministic to hold on BoRR till first EoR= is seen.

 

IMHO it should be also spelled out what is the expected sequenc= e error handling here

 

[Bruno] &#= 43;1.  And taking into account possible interaction with draft-ietf-id= r-bgp-gr-notification<= /p>

 

BTW:

“Whe= n the BGP speaker detects an error while processing a ROUTE-REFRESH message= with a non-zero "Message Subtype" field, it MUST send a NOTIFICA= TION message with Error Code "ROUTE-REFRESH Message Error".”

 

Seems a pr= iori not inline with the recommendation from draft-ietf-grow-ops-reqs-for-b= gp-error-handling (which is to limit the consequences of error handling). Are we sure that no error condition could be handled in a more = friendly way? (e.g. if BoRR is not sent following a “normal route ref= resh request” or if 2 BoRR are sent consecutively…)

 

Thanks,

Regards,

Bruno

 

 

... I th= ink not following "MUST NOT" shall implicitly result in entire se= ssion drop and complete restart ? Any error code ?

 

Best,
R.

 

 

On Wed, Jan 29, 2014 at = 9:22 AM, Dongjie (Jimmy) <jie.dong@huawei.com> wrote:

Hi Robert,

 

Agree that in these case= s the RRQ cannot be ignored, so postpone may be a better choice.

 

While IMO stop the initi= al update and start over may delay the initial convergence, and as you said  it also relates to update group processing. What do = you think about the new text provided by Keyur?

 

Best regards,

Jie

 

From:rraszuk@gmail.com [mailto:rraszuk@gma= il.com] On Behalf Of Robert Raszuk
Sent: Sunday, January 26, 2014 11:03 PM
To: Dongjie (Jimmy)
Cc: Keyur Patel (keyupate); Jakob Heitz; idr@ietf.org


Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refre= sh

 

Hi Jie,

 

I think it actually very easy to say that initial update can n= ot ever guarantee that RRQ received during its sending may meet the peer's need.

 

Example 1:

 

SAFI 128 - During receiving initial update from RR to PE new V= RF got added with new RT import. Unfortunately those updates received within initial update were already dropped as not interes= ting by the PE. RR must resend full table after completed initial update. (= Of course this is the case where there is no RTC and that's why RTC helps a= lot here by incremental nature). <= o:p>

 

Example 2: =

 

SAFI 1 - Operator has modified inbound policy on EBGP peer dur= ing processing of incoming updates and those originally were dropped. No soft reconfig in set. 

 

Conclusion:

 

RRQ can not ever be ignored. Sure they can be delayed or batch= ed (case of multiple peers within the same update/peer group) sending near RRQs (cluster of PEs got provisioned from central mana= gement station). But as Keyur already mentioned those are rather standard l= ocal implementation optimizations. =

 

Question:=

 

Does it maybe make sense to stop initial update when receiving= RRQ from a peer and start over ? Of course if peer is part of large update group it would have to be removed dynamically from= it so other members are not delayed. In any case I think this does not imp= act the spec but the implementation.

 

Cheers,
R.

 

 

 

On Sun, Jan 26, 2014 at= 7:13 PM, Dongjie (Jimmy) <jie.dong@huawei.com> wrote:

Hi Keyur, Jakob,

Agree that "postpone" may be better. The point is we could avoid = the complicated cases/considerations of performing route refresh during ini= tial update:)

For "ignore", I was thinking of scenarios in which the route refr= esh requirement may already be met by the initial update, while I'd admit i= t is hard to say...



Best regards,
Jie

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

From: Keyur Patel (keyu= pate) [mailto:keyup= ate@cisco.com]
Sent: Sunday, January 26, 2014 8:30 PM
To: Jakob Heitz; Dongjie (Jimmy)
Cc: idr@ietf.org
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Jie,

I agree with Jakob. You could make it *an implementation behavior* to postp= one the route refresh reply.


Regards,
Keyur

On 1/26/14 1:29 AM, "Jakob Heitz" <jakob.heitz@ericsson.com> wrote:<= br>
>You can definitely not ignore it, but you could postpone it.
>
>--
>Jakob Heitz.
>
>> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" <jie.dong@huawei.com>
>>wrote:
>>
>> After reading the analyses in this thread, my personal feeling is<= br> >>maybe we should avoid the interleaving between GR initial update an= d
>>route refresh/enhanced route refresh, since the initial update is j= ust
>>sending the whole Adj-RIB-Out, there is no obvious advantage to sta= rt
>>a route refresh/enhance route refresh during it. So a speaker shoul= d
>>ignore the RRQ received during the initial update. Thoughts?
>>
>> Best regards,
>> Jie
>>
>> -----Original Message-----
>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz
>> Sent: Saturday, January 25, 2014 10:48 PM
>> To: Chris Hall; = idr@ietf.org
>> Subject: Re: [Idr] WG LC for
>> draft-ietf-idr-bgp-enhanced-route-refresh
>>
>> RFCs are written for coders "practiced" in the art"= .
>> If anyone sends an EoRR before the adj-RIB-out is fully populated,=
>>then it's a BUG.
>> This does not need to be said.
>>
>> Personally, I believe a route refresh request should not be honore= d
>>until GR is complete.
>> Also, I don't believe a timer for the receipt of EoRR is necessary= ,
>>because the EoRR is guaranteed.
>> Guaranteed means "unless the session drops first".
>> --
>>
>> Jakob Heitz.
>>
>> ________________________________________
>> From: Chris Hall [chris.hall@highwayman.com]
>> Sent: Saturday, 25 January 2014 11:27 AM
>> To: idr@ietf.org=
>> Cc: Jakob Heitz
>> Subject: RE: [Idr] WG LC for
>> draft-ietf-idr-bgp-enhanced-route-refresh
>>
>> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37):
>> ...
>>> Silence means don't do it.
>>
>> Hmmm.... as a principle I'm more comfortable with "that which= isn't
>>prohibited is permitted"....
>>
>>> You would definitely NOT want BoRR to flush old stales.
>>
>> ....but, given the definite requirement, and given that the curren= t
>>precedent for "marking stale" does flush old stale, then = a few words
>>for the avoidance of doubt ?
>>
>>> Restarting the timer might be a good idea.
>>
>> I dunno... a route which remains stale for "a long time"= is, of
>>course, a candidate for being withdrawn: so having started a timer = the
>>first time things are set stale, I would avoid extending that -- at=
>>least for Graceful Restart, where the whole withdraw thing has been= "on-hold"
>>since the last session failed.  For route-refresh I guess ther= e's more
>>of a presumption that stale routes will be refreshed sooner or late= r,
>>and in the meantime they remain good.  So if the route-refresh= is
>>(repeatedly) restarted for some reason, perhaps it is more reasonab= le
>>to extend the flush deadline -- but avoid doing this indefinitely ?=
>>
>> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I ha= ve
>>built in Quagga prioritise route changes (pending changes and any t= hat
>>occur during the refresh) over refresh updates.  This makes it= more
>>likely that remaining stale routes are still good.  But the ot= her end
>>cannot know that.
>>
>> The paragraph in the draft discussing the "entire Adj-RIB-Out= "
>>defines that to be the entries present "at the start of the ro= ute
>>refresh operation", and observes that these comprise both reac= hable
>>and unreachable routes.  [An "of" after "compri= se" sets teeth on edge,
>>BTW.]  I'm really not sure what this paragraph is trying to te= ll me.
>> The reference to unreachable routes appears to suggest that pendin= g
>>withdraws should be sent as part of the refresh -- so not left to t= he
>>EoRR to implement at the end.  The point at which the EoRR is = sent is
>>defined such that it excludes any Adj-RIB-Out entries added after t= he
>>route-refresh started, but includes any which are changed during th= e
>>process.  It seems reasonable to delay any brand new reachable=
>>prefixes until after all previously announced ones have been refres= hed
>>and the EoRR sent -- if that's the intent here.  Changes which= occur
>>before the refresh gets to a given entry are pretty naturally swept= up
>>by the refresh.  Changes which occur after the refresh has gon= e past,
>>could/should be deferred to after the EoRR ?  Does it make a >>difference if the change is a withdraw ?  (Of course MRAI may = kick in here.  Ah.
>>MRAI and route-refresh, there's a topic !)
>>
>> I think the essence of the rule is that the EoRR should be sent on= ce
>>all prefixes previously advertised to the peer as reachable have be= en
>>refreshed, ie announced or withdrawn (at least) once.  Or, per= haps
>>more strictly, not *before* those prefixes have *all* been announce= d
>>once -- given that the EoRR will promptly bang un-advertised stuff = on the head.
>>Even more strictly perhaps: not send EoRR *before* any withdraws
>>implied by it are required or desirable.
>>
>> Depending on the implementation, a given sender may or may not be<= br> >>able to determine the minimum set of updates required before sendin= g EoRR.
>>
>> If the refresh operation takes a long time, there may be good
>>routeing reasons to arrange for some route changes to be sent to th= e peer "early"
>>-- that is to send announcements which do not contribute to the
>>refresh, but which are important enough to warrant delaying the end= of
>>the refresh.  That could be a matter for recommendation(s) in = the standard.
>>
>> NB: given that the timing of the EoRR is tied to the state of the<= br> >>Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. &= nbsp;At
>>the beginning of the initial update, the Restarting and Receiving >>speakers have:
>>
>>  Restarting:  Empty Adj-RIB-In   Empty Adj-RIB-Out<= br> >>
>>  Receiving:   Empty Adj-RIB-Out  Stale Adj-RIB-In >>
>> Now suppose (bonkers or otherwise) the receiving speaker sends an = RRQ
>>part way through the initial update.  The restarting speaker r= esponds
>>with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specifica= tion.
>> The receiving speaker sees the EoRR, and flushes stale.
>>Unfortunately, if the restarting speaker has not yet fully populate= d
>>its Adj-RIB-Out, then many further routes will be sent before the E= oR
>>falls due -- but the receiving speaker has already flushed their ti= ny
>>posteriors :-(
>>
>> I am coming to the view that route-refresh during a Graceful Resta= rt
>>initial update is a horse of a different colour altogether.
>>
>> [So the assumption that EoRR and EoR are triggered by the same thi= ng
>>was completely wrong, and I apologise for it.]
>>
>> Chris
>>
>> _______________________________________________
>> 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
htt= ps://www.ietf.org/mailman/listinfo/idr

 

 = 

__________________________________________=
___________________________________________________________________________=
____
 
Ce message et ses pieces jointes peuvent c=
ontenir des informations confidentielles ou privilegiees et ne doivent donc=

pas etre diffuses, exploites ou copies san=
s autorisation. Si vous avez recu ce message par erreur, veuillez le signal=
er
a l'expediteur et le detruire ainsi que le=
s pieces jointes. Les messages electroniques etant susceptibles d'alteratio=
n,
Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may conta=
in confidential or privileged information that may be protected by law;
they should not be distributed, used or co=
pied without authorisation.
If you have received this email in error, =
please notify the sender and delete this message and its attachments.<=
/o:p>
As emails may be altered, Orange is not li=
able for messages that have been modified, changed or falsified.=

Thank you.
______________________________________________________________________=
___________________________________________________

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,
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 authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A070E0357PEXCVZYM11corpo_-- From chris.hall@highwayman.com Thu Jan 30 04:16:15 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E781A02D4 for ; Thu, 30 Jan 2014 04:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.16 X-Spam-Level: X-Spam-Status: No, score=0.16 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-wa-9G-BGEg for ; Thu, 30 Jan 2014 04:16:14 -0800 (PST) Received: from smtp.demon.co.uk (mdfmta009.mxout.tbr.inty.net [91.221.168.50]) by ietfa.amsl.com (Postfix) with ESMTP id CFB6A1A0233 for ; Thu, 30 Jan 2014 04:16:13 -0800 (PST) Received: from mdfmta009.tbr.inty.net (unknown [127.0.0.1]) by mdfmta009.tbr.inty.net (Postfix) with ESMTP id D3923384082 for ; Thu, 30 Jan 2014 12:16:09 +0000 (GMT) Received: from mdfmta009.tbr.inty.net (unknown [127.0.0.1]) by mdfmta009.tbr.inty.net (Postfix) with ESMTP id B970E384081 for ; Thu, 30 Jan 2014 12:16:09 +0000 (GMT) Received: from hestia.halldom.com (unknown [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta009.tbr.inty.net (Postfix) with ESMTP for ; Thu, 30 Jan 2014 12:16:09 +0000 (GMT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by hestia.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1W8qXQ-0007Lf-UD for idr@ietf.org; Thu, 30 Jan 2014 12:16:08 +0000 From: "Chris Hall" To: References: <010801cf1c8c$6b1a0420$414e0c60$@ndzh.com> <8ED5B0B0F5B4854A912480C1521F973A11AFBD56@xmb-rcd-x13.cisco.com> <6D84FB20-2A48-4830-92F5-C81C5F4AA36A@exa-networks.co.uk> <8ED5B0B0F5B4854A912480C1521F973A11AFCCA6@xmb-rcd-x13.cisco.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F7116F@eusaamb109.ericsson.se> In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F7116F@eusaamb109.ericsson.se> Date: Thu, 30 Jan 2014 12:16:03 -0000 Organization: Highwayman Message-ID: <0c4501cf1db5$0eaae2c0$2c00a840$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIVQdHzpYvkm0BCTmodJao1+Yeh6wJwxkzzAi3c/cwCTiJCLQMTRmqDAWamBT0Bi+OUrJmpRyOg Content-Language: en-gb X-MDF-HostID: 4 Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 12:16:15 -0000 Jakob Heitz wrote (on Thu 30-Jan-2014 at 01:53 +0000): ..... > If an EoRR deletes an unexpected stale route, it should be logged > and debugged. Notwithstanding routes deleted by policy changes. This puts an onus on the sender to send unreachable as well as reachable advertisements for all prefixes believed known by the receiver. And hence... although on EoRR the receiver MUST withdraw anything not mentioned since the BoRR, the sender SHOULD/MUST NOT depend on that as a means to withdraw prefixes. Chris From keyupate@cisco.com Thu Jan 30 06:48:16 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6E21A0374 for ; Thu, 30 Jan 2014 06:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OzeCbPTJpWoG for ; Thu, 30 Jan 2014 06:48:10 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 22B801A036B for ; Thu, 30 Jan 2014 06:48:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=70896; q=dns/txt; s=iport; t=1391093287; x=1392302887; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=CA/QABXgbrlg79w3gcxF7bOEpBvKGkLqmKA3NAfJhEs=; b=hLEeT5MFIm0qt20FSNxYGwfxlKRnpRYfwX2irtBKTjTolVUZvYqc3M4b UC0EC1lQ08h4C9+wBtv2GB2m4iRUQ+EdPraZ5cCS5ZBJ17PQ8cKkCzC9g F0gY81zDj1harhJorBZR+mW9iycbbngfhAqiSBiUHNkam/eerhh/bMuZd Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkFAHpl6lKtJXG+/2dsb2JhbABZgkhEOFe9JYEJFnSCJQEBAQQBAQEJDgESQQsMBgEIEQMBAQEWCwEGKAYLFAkIAgQOBYdxAxENqhWYQA2JHBMEjGyBNAsGAT8MAQQGAQYEhC4EljyBbIxehUGDLYFoAQYCFyI X-IronPort-AV: E=Sophos;i="4.95,750,1384300800"; d="scan'208,217";a="16701213" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-1.cisco.com with ESMTP; 30 Jan 2014 14:48:05 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0UEm5U4020783 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Jan 2014 14:48:05 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.228]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Thu, 30 Jan 2014 08:48:05 -0600 From: "Keyur Patel (keyupate)" To: "bruno.decraene@orange.com" Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPHcpHkeX0Ff7T2kONFJ6OHVSLvw== Date: Thu, 30 Jan 2014 14:48:04 +0000 Message-ID: In-Reply-To: <22670_1391077677_52EA292D_22670_18044_1_53C29892C857584299CBF5D05346208A070E0357@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.21.87.64] Content-Type: multipart/alternative; boundary="_000_CF0FA554615F7keyupateciscocom_" MIME-Version: 1.0 Cc: "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 14:48:16 -0000 --_000_CF0FA554615F7keyupateciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Bruno, Comments Inlined #Keyur. From: > Date: Thu, 30 Jan 2014 10:27:56 +0000 To: Keyur Patel > Cc: "idr@ietf.org" > Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Keyur, Thanks for your reply. Your proposed new text, using NOTIFICATION only for syntax errors seems muc= h better to me. Thanks for the clarification. Ideally, in addition, I would prefer to have a text also covering other typ= es of errors. At least the violation of explicit statement in the draft. E.= g. for the following 2 MUST =93 Before the speaker starts a route refresh that is either initiated locally, or in response to a "normal route refresh request" from the peer, the speaker MUST send a BoRR message. After the speaker completes the re-advertisement of the entire Adj-RIB-Out to the peer, it MUST send an EoRR message.=94 Regarding the first one, IMHO there is no harm if the MUST is not enforced.= One option may be :s/MUST/SHOULD; or a statement in =A7 =93Error handling= =94 on how to handle this error (e.g. log and nothing else). Regarding the second one, I=92d like to see a text specifying what should b= e done when I receive two BoRR. E.g. -a- consider that the second BoRR should be considered as a EoRR+ BoRR -b- ignore/abort the first EoRR procedure (i.e. remark all routes as STALE = when the second EoRR is received) -c- ignore the second EoRR. #Keyur: If the sender has sent two BoRRs (without an EoRR) then it means it= has aborted the first route refresh table announcement and restarted the r= oute refresh table announcement. The second EoRR will be essentially no-op = (I.e C case). Implementations can log the no-op behavior. Regards, Keyur (plus obviously log the error in all cases) =93a=94 sounds dangerous to me. =93b=94 should a priori ok (accept a small error but consider that the spea= ker remember (and acted as per) its latest message.) =93c=94 is the safest path (there is a error, I don=92t know what it is so = I take the safest option) Considering the motivation for this draft (enhance BGP robustness, but not = bring a new feature), I think I would prefer =93c=94 which is the more robu= st. Especially given that if the receiver has a doubt, I has a way to clear= it by sending a new Route Refresh message. But I guess I would be fine with =93b=94 if you/the WG have a different opi= nion. (My understanding of the current draft, is that =93b=94 is expected, but in= all cases I would prefer a specific text in =A7 =93Error handling=94) Thanks, Cheers, Bruno From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] Sent: Wednesday, January 29, 2014 11:16 PM To: DECRAENE Bruno IMT/OLN; Robert Raszuk Cc: idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Bruno, We only generate Notification for invalid length. Apologies for the confusi= on. Attached is the revised text. Regards, Keyur The error handling specified in this section is applicable only when a BGP speaker has received the "Enhanced Route Refresh Capability" from a peer. If the length, excluding the fixed-size message header, of the received ROUTE-REFRESH message with Message Subtype 1 and 2 is not 4, then the BGP speaker MUST send a NOTIFICATION message with the Error Code of "ROUTE-REFRESH Message Error" and the subcode of "Invalid Message Length". The Data field of the NOTIFICATION message MUST contain the complete ROUTE-REFRESH message. When the BGP speaker receives a ROUTE-REFRESH message with a "Message Subtype" field other than 1 or 2, it MUST ignore the received ROUTE- REFRESH message. It SHOULD log an error for further analysis. From: > Date: Wed, 29 Jan 2014 09:51:00 +0000 To: Robert Raszuk >, Keyur Pate= l > Cc: "idr@ietf.org" > Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi all, From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: Wednesday, January 29, 2014 10:15 AM To: Dongjie (Jimmy) Cc: Keyur Patel (keyupate); idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Jimmy and all, I think Enke and Keyur's proposed text with help from Jakob makes the behav= ior simplified and deterministic to hold on BoRR till first EoR is seen. IMHO it should be also spelled out what is the expected sequence error hand= ling here [Bruno] +1. And taking into account possible interaction with draft-ietf-i= dr-bgp-gr-notification BTW: =93When the BGP speaker detects an error while processing a ROUTE-REFRESH m= essage with a non-zero "Message Subtype" field, it MUST send a NOTIFICATION= message with Error Code "ROUTE-REFRESH Message Error".=94 Seems a priori not inline with the recommendation from draft-ietf-grow-ops-= reqs-for-bgp-error-handling (which is to limit the consequences of error ha= ndling). Are we sure that no error condition could be handled in a more fri= endly way? (e.g. if BoRR is not sent following a =93normal route refresh re= quest=94 or if 2 BoRR are sent consecutively=85) Thanks, Regards, Bruno ... I think not following "MUST NOT" shall implicitly result in entire sess= ion drop and complete restart ? Any error code ? Best, R. On Wed, Jan 29, 2014 at 9:22 AM, Dongjie (Jimmy) > wrote: Hi Robert, Agree that in these cases the RRQ cannot be ignored, so postpone may be a b= etter choice. While IMO stop the initial update and start over may delay the initial conv= ergence, and as you said it also relates to update group processing. What = do you think about the new text provided by Keyur? Best regards, Jie From:rraszuk@gmail.com [mailto:rraszuk@gmail.com<= mailto:rraszuk@gmail.com>] On Behalf Of Robert Raszuk Sent: Sunday, January 26, 2014 11:03 PM To: Dongjie (Jimmy) Cc: Keyur Patel (keyupate); Jakob Heitz; idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Jie, I think it actually very easy to say that initial update can not ever guara= ntee that RRQ received during its sending may meet the peer's need. Example 1: SAFI 128 - During receiving initial update from RR to PE new VRF got added = with new RT import. Unfortunately those updates received within initial upd= ate were already dropped as not interesting by the PE. RR must resend full = table after completed initial update. (Of course this is the case where the= re is no RTC and that's why RTC helps a lot here by incremental nature). Example 2: SAFI 1 - Operator has modified inbound policy on EBGP peer during processin= g of incoming updates and those originally were dropped. No soft reconfig i= n set. Conclusion: RRQ can not ever be ignored. Sure they can be delayed or batched (case of m= ultiple peers within the same update/peer group) sending near RRQs (cluster= of PEs got provisioned from central management station). But as Keyur alre= ady mentioned those are rather standard local implementation optimizations. Question: Does it maybe make sense to stop initial update when receiving RRQ from a p= eer and start over ? Of course if peer is part of large update group it wou= ld have to be removed dynamically from it so other members are not delayed.= In any case I think this does not impact the spec but the implementation. Cheers, R. On Sun, Jan 26, 2014 at 7:13 PM, Dongjie (Jimmy) > wrote: Hi Keyur, Jakob, Agree that "postpone" may be better. The point is we could avoid the compli= cated cases/considerations of performing route refresh during initial updat= e:) For "ignore", I was thinking of scenarios in which the route refresh requir= ement may already be met by the initial update, while I'd admit it is hard = to say... Best regards, Jie -----Original Message----- From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] Sent: Sunday, January 26, 2014 8:30 PM To: Jakob Heitz; Dongjie (Jimmy) Cc: idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Jie, I agree with Jakob. You could make it *an implementation behavior* to postp= one the route refresh reply. Regards, Keyur On 1/26/14 1:29 AM, "Jakob Heitz" > wrote: >You can definitely not ignore it, but you could postpone it. > >-- >Jakob Heitz. > >> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" > >>wrote: >> >> After reading the analyses in this thread, my personal feeling is >>maybe we should avoid the interleaving between GR initial update and >>route refresh/enhanced route refresh, since the initial update is just >>sending the whole Adj-RIB-Out, there is no obvious advantage to start >>a route refresh/enhance route refresh during it. So a speaker should >>ignore the RRQ received during the initial update. Thoughts? >> >> Best regards, >> Jie >> >> -----Original Message----- >> From: Idr [mailto:idr-bounces@ietf.org] On = Behalf Of Jakob Heitz >> Sent: Saturday, January 25, 2014 10:48 PM >> To: Chris Hall; idr@ietf.org >> Subject: Re: [Idr] WG LC for >> draft-ietf-idr-bgp-enhanced-route-refresh >> >> RFCs are written for coders "practiced" in the art". >> If anyone sends an EoRR before the adj-RIB-out is fully populated, >>then it's a BUG. >> This does not need to be said. >> >> Personally, I believe a route refresh request should not be honored >>until GR is complete. >> Also, I don't believe a timer for the receipt of EoRR is necessary, >>because the EoRR is guaranteed. >> Guaranteed means "unless the session drops first". >> -- >> >> Jakob Heitz. >> >> ________________________________________ >> From: Chris Hall [chris.hall@highwayman.com] >> Sent: Saturday, 25 January 2014 11:27 AM >> To: idr@ietf.org >> Cc: Jakob Heitz >> Subject: RE: [Idr] WG LC for >> draft-ietf-idr-bgp-enhanced-route-refresh >> >> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): >> ... >>> Silence means don't do it. >> >> Hmmm.... as a principle I'm more comfortable with "that which isn't >>prohibited is permitted".... >> >>> You would definitely NOT want BoRR to flush old stales. >> >> ....but, given the definite requirement, and given that the current >>precedent for "marking stale" does flush old stale, then a few words >>for the avoidance of doubt ? >> >>> Restarting the timer might be a good idea. >> >> I dunno... a route which remains stale for "a long time" is, of >>course, a candidate for being withdrawn: so having started a timer the >>first time things are set stale, I would avoid extending that -- at >>least for Graceful Restart, where the whole withdraw thing has been "on-h= old" >>since the last session failed. For route-refresh I guess there's more >>of a presumption that stale routes will be refreshed sooner or later, >>and in the meantime they remain good. So if the route-refresh is >>(repeatedly) restarted for some reason, perhaps it is more reasonable >>to extend the flush deadline -- but avoid doing this indefinitely ? >> >> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I have >>built in Quagga prioritise route changes (pending changes and any that >>occur during the refresh) over refresh updates. This makes it more >>likely that remaining stale routes are still good. But the other end >>cannot know that. >> >> The paragraph in the draft discussing the "entire Adj-RIB-Out" >>defines that to be the entries present "at the start of the route >>refresh operation", and observes that these comprise both reachable >>and unreachable routes. [An "of" after "comprise" sets teeth on edge, >>BTW.] I'm really not sure what this paragraph is trying to tell me. >> The reference to unreachable routes appears to suggest that pending >>withdraws should be sent as part of the refresh -- so not left to the >>EoRR to implement at the end. The point at which the EoRR is sent is >>defined such that it excludes any Adj-RIB-Out entries added after the >>route-refresh started, but includes any which are changed during the >>process. It seems reasonable to delay any brand new reachable >>prefixes until after all previously announced ones have been refreshed >>and the EoRR sent -- if that's the intent here. Changes which occur >>before the refresh gets to a given entry are pretty naturally swept up >>by the refresh. Changes which occur after the refresh has gone past, >>could/should be deferred to after the EoRR ? Does it make a >>difference if the change is a withdraw ? (Of course MRAI may kick in her= e. Ah. >>MRAI and route-refresh, there's a topic !) >> >> I think the essence of the rule is that the EoRR should be sent once >>all prefixes previously advertised to the peer as reachable have been >>refreshed, ie announced or withdrawn (at least) once. Or, perhaps >>more strictly, not *before* those prefixes have *all* been announced >>once -- given that the EoRR will promptly bang un-advertised stuff on the= head. >>Even more strictly perhaps: not send EoRR *before* any withdraws >>implied by it are required or desirable. >> >> Depending on the implementation, a given sender may or may not be >>able to determine the minimum set of updates required before sending EoRR= . >> >> If the refresh operation takes a long time, there may be good >>routeing reasons to arrange for some route changes to be sent to the peer= "early" >>-- that is to send announcements which do not contribute to the >>refresh, but which are important enough to warrant delaying the end of >>the refresh. That could be a matter for recommendation(s) in the standar= d. >> >> NB: given that the timing of the EoRR is tied to the state of the >>Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. At >>the beginning of the initial update, the Restarting and Receiving >>speakers have: >> >> Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out >> >> Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In >> >> Now suppose (bonkers or otherwise) the receiving speaker sends an RRQ >>part way through the initial update. The restarting speaker responds >>with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specification. >> The receiving speaker sees the EoRR, and flushes stale. >>Unfortunately, if the restarting speaker has not yet fully populated >>its Adj-RIB-Out, then many further routes will be sent before the EoR >>falls due -- but the receiving speaker has already flushed their tiny >>posteriors :-( >> >> I am coming to the view that route-refresh during a Graceful Restart >>initial update is a horse of a different colour altogether. >> >> [So the assumption that EoRR and EoR are triggered by the same thing >>was completely wrong, and I apologise for it.] >> >> Chris >> >> _______________________________________________ >> 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 ___________________________________________________________________________= ______________________________________________ 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, 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 authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ 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, 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 authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_CF0FA554615F7keyupateciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <6F2C770CD13EE04897DA5E3CB4BAAFDB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Bruno,

Comments Inlined #Keyur.

From: <bruno.decraene@orange.com>
Date: Thu, 30 Jan 2014 10:27:56 = 3;0000
To: Keyur Patel <keyupate@cisco.com>
Cc: "idr@ietf.org" <idr@ietf.= org>
Subject: RE: [Idr] WG LC for draft-= ietf-idr-bgp-enhanced-route-refresh

Hi Keyur,

 

Thanks for your rep= ly.

Your proposed new t= ext, using NOTIFICATION only for syntax errors seems much better to me. Tha= nks for the clarification.

 

Ideally, in additio= n, I would prefer to have a text also covering other types of errors. At le= ast the violation of explicit statement in the draft. E.g. for the following 2 MUST

=93   Before the speaker starts a route = refresh that is either initiated

   locally, or in response to a "no= rmal route refresh request" from the

   peer, the speaker MUST send a B= oRR message.  After the speaker

   completes the re-advertisement of the= entire Adj-RIB-Out to the peer,

   it MUST send an = EoRR message.=94

 

Regarding the first= one, IMHO there is no harm if the MUST is not enforced. One option may be = :s/MUST/SHOULD; or a statement in =A7 =93Error handling=94 on how to handle this error (e.g. log and nothing else).<= /o:p>

Regarding the secon= d one, I=92d like to see a text specifying what should be done when I recei= ve two BoRR. E.g.

-a- consider that t= he second BoRR should be considered as a EoRR+ BoRR

-b- ignore/abort th= e first EoRR procedure (i.e. remark all routes as STALE when the second EoR= R is received)

-c- ignore the seco= nd EoRR.

 
#Keyur: If the sender has sent two BoRRs (without an EoRR) then it mea= ns it has aborted the first route refresh table announcement and restarted = the route refresh table announcement. The second EoRR will be essentially n= o-op (I.e C case). Implementations can log the no-op behavior.

Regards,
Keyur
 

(plus obviously log= the error in all cases)

 

=93a=94 sounds dang= erous to me.

=93b=94 should a pr= iori ok (accept a small error but consider that the speaker remember (and a= cted as per) its latest message.)

=93c=94 is the safe= st path (there is a error, I don=92t know what it is so I take the safest o= ption)

 

Considering the mot= ivation for this draft (enhance BGP robustness, but not bring a new feature= ), I think I would prefer =93c=94 which is the more robust. Especially given that if the receiver has a doubt, I has = a way to clear it by sending a new Route Refresh message.=

But I guess I would= be fine with =93b=94 if you/the WG have a different opinion.

(My understanding o= f the current draft, is that =93b=94 is expected, but in all cases I would = prefer a specific text in  =A7 =93Error handling=94)=

 

Thanks,<= /span>

Cheers,<= /span>

Bruno

 

 

From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com]
Sent: Wednesday, January 29, 2014 11:16 PM
To: DECRAENE Bruno IMT/OLN; Robert Raszuk
Cc: idr@ietf.org
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refre= sh

 

Hi Bruno,

 

We only generate Notification for invalid l= ength. Apologies for the confusion. Attached is the revised text.

 

Regards,

Keyur

 

<snip>

The error handling specified in this sectio= n is applicable only when

   a BGP speaker has received the= "Enhanced Route Refresh Capability"

   from a peer.=

 

   If the length, excluding the f= ixed-size message header, of the

   received ROUTE-REFRESH message= with Message Subtype 1 and 2 is not 4,

   then the BGP speaker MUST send= a NOTIFICATION message with the Error

   Code of "ROUTE-REFRESH Me= ssage Error" and the subcode of "Invalid

   Message Length".  Th= e Data field of the NOTIFICATION message MUST

   contain the complete ROUTE-REF= RESH message.

 

   When the BGP speaker receives = a ROUTE-REFRESH message with a "Message

   Subtype" field other than= 1 or 2, it MUST ignore the received ROUTE-

   REFRESH message.  It SHOU= LD log an error for further analysis.

 

<snip>

 

From: <bruno.de= craene@orange.com>
Date: Wed, 29 Jan 2014 09:51:00 +0000
To: Robert Raszuk <robert@ra= szuk.net>, Keyur Patel <key= upate@cisco.com>
Cc: "idr@ietf.org" <= ;idr@ietf.org>
Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refre= sh

 

Hi all,

 

 

From: Idr [mailto:idr-bounces= @ietf.org] On Behalf Of Robert Raszuk
Sent: Wednesday, January 29, 2014 10:15 AM
To: Dongjie (Jimmy)
Cc: Keyur Patel (keyupate); idr@ietf= .org
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refre= sh

 

Hi Jimmy and all,

 

I think Enke and Keyur's proposed text with help from Jakob makes th= e behavior simplified and deterministic to hold on BoRR till first EoR is s= een.

 

IMHO it should be also spelled out what is the expected sequence err= or handling here

 

[Bruno] +1. &nb= sp;And taking into account possible interaction with draft-ietf-idr-bgp-gr-= notification

 

BTW:

=93When the BGP spe= aker detects an error while processing a ROUTE-REFRESH message with a non-z= ero "Message Subtype" field, it MUST send a NOTIFICATION message with Error Code "ROUTE-REFRESH Message Error&q= uot;.=94

 

Seems a priori not = inline with the recommendation from draft-ietf-grow-ops-reqs-for-bgp-error-= handling (which is to limit the consequences of error handling). Are we sure that no error condition could be handled i= n a more friendly way? (e.g. if BoRR is not sent following a =93normal rout= e refresh request=94 or if 2 BoRR are sent consecutively=85)

 

Thanks,

Regards,

Bruno

 

 

... I think n= ot following "MUST NOT" shall implicitly result in entire session= drop and complete restart ? Any error code ?

 

Best,
R.

 

 

On Wed, Jan 29, 2014 at = 9:22 AM, Dongjie (Jimmy) <jie.dong@huawei.com> wrote:

Hi Robert,

 

Agree that in these cases the R= RQ cannot be ignored, so postpone may be a better choice.

 

While IMO stop the initial upda= te and start over may delay the initial convergence, and as you said  it also relates to update group process= ing. What do you think about the new text provided by Keyur?

 

Best regards,

Jie

 

From:rraszuk@gmail.com [mailto:rraszuk@gma= il.com] On Behalf Of Robert Raszuk
Sent: Sunday, January 26, 2014 11:03 PM
To: Dongjie (Jimmy)
Cc: Keyur Patel (keyupate); Jakob Heitz; idr@ietf.org


Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refre= sh

 

Hi Jie,

 

I think it actually very easy to say that initial update can not ev= er guarantee that RRQ received during its sending may meet the peer's need.<= /o:p>

 

Example 1:

 

SAFI 128 - During receiving initial update from RR to PE new VRF go= t added with new RT import. Unfortunately those updates received within initial update were already dropped as not i= nteresting by the PE. RR must resend full table after completed initial upd= ate. (Of course this is the case where there is no RTC and that's why RTC h= elps a lot here by incremental nature). 

 

Example 2: 

 

SAFI 1 - Operator has modified inbound policy on EBGP peer during p= rocessing of incoming updates and those originally were dropped. No soft reconfig in set. 

 

Conclusion:

 

RRQ can not ever be ignored. Sure they can be delayed or batched (c= ase of multiple peers within the same update/peer group) sending near RRQs (cluster of PEs got provisioned from central mana= gement station). But as Keyur already mentioned those are rather standard l= ocal implementation optimizations. =

 

Question:

 

Does it maybe make sense to stop initial update when receiving RRQ = from a peer and start over ? Of course if peer is part of large update group it would have to be removed dynamically= from it so other members are not delayed. In any case I think this does no= t impact the spec but the implementation.

 

Cheers,
R.

 

 

 

On Sun, Jan 26, 2014 at= 7:13 PM, Dongjie (Jimmy) <jie.dong@huawei.com> wrote:

Hi Keyur, Jakob,

Agree that "postpone" may be better. The point is we could avoid = the complicated cases/considerations of performing route refresh during ini= tial update:)

For "ignore", I was thinking of scenarios in which the route refr= esh requirement may already be met by the initial update, while I'd admit i= t is hard to say...



Best regards,
Jie

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

From: Keyur Patel (keyu= pate) [mailto:keyup= ate@cisco.com]
Sent: Sunday, January 26, 2014 8:30 PM
To: Jakob Heitz; Dongjie (Jimmy)
Cc: idr@ietf.org
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Jie,

I agree with Jakob. You could make it *an implementation behavior* to postp= one the route refresh reply.


Regards,
Keyur

On 1/26/14 1:29 AM, "Jakob Heitz" <jakob.heitz@ericsson.com> wrote:<= br>
>You can definitely not ignore it, but you could postpone it.
>
>--
>Jakob Heitz.
>
>> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" <jie.dong@huawei.com>
>>wrote:
>>
>> After reading the analyses in this thread, my personal feeling is<= br> >>maybe we should avoid the interleaving between GR initial update an= d
>>route refresh/enhanced route refresh, since the initial update is j= ust
>>sending the whole Adj-RIB-Out, there is no obvious advantage to sta= rt
>>a route refresh/enhance route refresh during it. So a speaker shoul= d
>>ignore the RRQ received during the initial update. Thoughts?
>>
>> Best regards,
>> Jie
>>
>> -----Original Message-----
>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz
>> Sent: Saturday, January 25, 2014 10:48 PM
>> To: Chris Hall; = idr@ietf.org
>> Subject: Re: [Idr] WG LC for
>> draft-ietf-idr-bgp-enhanced-route-refresh
>>
>> RFCs are written for coders "practiced" in the art"= .
>> If anyone sends an EoRR before the adj-RIB-out is fully populated,=
>>then it's a BUG.
>> This does not need to be said.
>>
>> Personally, I believe a route refresh request should not be honore= d
>>until GR is complete.
>> Also, I don't believe a timer for the receipt of EoRR is necessary= ,
>>because the EoRR is guaranteed.
>> Guaranteed means "unless the session drops first".
>> --
>>
>> Jakob Heitz.
>>
>> ________________________________________
>> From: Chris Hall [chris.hall@highwayman.com]
>> Sent: Saturday, 25 January 2014 11:27 AM
>> To: idr@ietf.org=
>> Cc: Jakob Heitz
>> Subject: RE: [Idr] WG LC for
>> draft-ietf-idr-bgp-enhanced-route-refresh
>>
>> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37):
>> ...
>>> Silence means don't do it.
>>
>> Hmmm.... as a principle I'm more comfortable with "that which= isn't
>>prohibited is permitted"....
>>
>>> You would definitely NOT want BoRR to flush old stales.
>>
>> ....but, given the definite requirement, and given that the curren= t
>>precedent for "marking stale" does flush old stale, then = a few words
>>for the avoidance of doubt ?
>>
>>> Restarting the timer might be a good idea.
>>
>> I dunno... a route which remains stale for "a long time"= is, of
>>course, a candidate for being withdrawn: so having started a timer = the
>>first time things are set stale, I would avoid extending that -- at=
>>least for Graceful Restart, where the whole withdraw thing has been= "on-hold"
>>since the last session failed.  For route-refresh I guess ther= e's more
>>of a presumption that stale routes will be refreshed sooner or late= r,
>>and in the meantime they remain good.  So if the route-refresh= is
>>(repeatedly) restarted for some reason, perhaps it is more reasonab= le
>>to extend the flush deadline -- but avoid doing this indefinitely ?=
>>
>> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I ha= ve
>>built in Quagga prioritise route changes (pending changes and any t= hat
>>occur during the refresh) over refresh updates.  This makes it= more
>>likely that remaining stale routes are still good.  But the ot= her end
>>cannot know that.
>>
>> The paragraph in the draft discussing the "entire Adj-RIB-Out= "
>>defines that to be the entries present "at the start of the ro= ute
>>refresh operation", and observes that these comprise both reac= hable
>>and unreachable routes.  [An "of" after "compri= se" sets teeth on edge,
>>BTW.]  I'm really not sure what this paragraph is trying to te= ll me.
>> The reference to unreachable routes appears to suggest that pendin= g
>>withdraws should be sent as part of the refresh -- so not left to t= he
>>EoRR to implement at the end.  The point at which the EoRR is = sent is
>>defined such that it excludes any Adj-RIB-Out entries added after t= he
>>route-refresh started, but includes any which are changed during th= e
>>process.  It seems reasonable to delay any brand new reachable=
>>prefixes until after all previously announced ones have been refres= hed
>>and the EoRR sent -- if that's the intent here.  Changes which= occur
>>before the refresh gets to a given entry are pretty naturally swept= up
>>by the refresh.  Changes which occur after the refresh has gon= e past,
>>could/should be deferred to after the EoRR ?  Does it make a >>difference if the change is a withdraw ?  (Of course MRAI may = kick in here.  Ah.
>>MRAI and route-refresh, there's a topic !)
>>
>> I think the essence of the rule is that the EoRR should be sent on= ce
>>all prefixes previously advertised to the peer as reachable have be= en
>>refreshed, ie announced or withdrawn (at least) once.  Or, per= haps
>>more strictly, not *before* those prefixes have *all* been announce= d
>>once -- given that the EoRR will promptly bang un-advertised stuff = on the head.
>>Even more strictly perhaps: not send EoRR *before* any withdraws >>implied by it are required or desirable.
>>
>> Depending on the implementation, a given sender may or may not be<= br> >>able to determine the minimum set of updates required before sendin= g EoRR.
>>
>> If the refresh operation takes a long time, there may be good
>>routeing reasons to arrange for some route changes to be sent to th= e peer "early"
>>-- that is to send announcements which do not contribute to the
>>refresh, but which are important enough to warrant delaying the end= of
>>the refresh.  That could be a matter for recommendation(s) in = the standard.
>>
>> NB: given that the timing of the EoRR is tied to the state of the<= br> >>Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. &= nbsp;At
>>the beginning of the initial update, the Restarting and Receiving >>speakers have:
>>
>>  Restarting:  Empty Adj-RIB-In   Empty Adj-RIB-Out<= br> >>
>>  Receiving:   Empty Adj-RIB-Out  Stale Adj-RIB-In >>
>> Now suppose (bonkers or otherwise) the receiving speaker sends an = RRQ
>>part way through the initial update.  The restarting speaker r= esponds
>>with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specifica= tion.
>> The receiving speaker sees the EoRR, and flushes stale.
>>Unfortunately, if the restarting speaker has not yet fully populate= d
>>its Adj-RIB-Out, then many further routes will be sent before the E= oR
>>falls due -- but the receiving speaker has already flushed their ti= ny
>>posteriors :-(
>>
>> I am coming to the view that route-refresh during a Graceful Resta= rt
>>initial update is a horse of a different colour altogether.
>>
>> [So the assumption that EoRR and EoR are triggered by the same thi= ng
>>was completely wrong, and I apologise for it.]
>>
>> Chris
>>
>> _______________________________________________
>> 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
htt= ps://www.ietf.org/mailman/listinfo/idr

 

 = 

__________________________________________=
___________________________________________________________________________=
____
 
Ce message et ses pieces jointes peuvent c=
ontenir des informations confidentielles ou privilegiees et ne doivent donc=

pas etre diffuses, exploites ou copies san=
s autorisation. Si vous avez recu ce message par erreur, veuillez le signal=
er
a l'expediteur et le detruire ainsi que le=
s pieces jointes. Les messages electroniques etant susceptibles d'alteratio=
n,
Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may conta=
in confidential or privileged information that may be protected by law;
they should not be distributed, used or co=
pied without authorisation.
If you have received this email in error, =
please notify the sender and delete this message and its attachments.<=
/o:p>
As emails may be altered, Orange is not li=
able for messages that have been modified, changed or falsified.=

Thank you.
______________________________________________________________________=
___________________________________________________

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,
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 authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_CF0FA554615F7keyupateciscocom_-- From bruno.decraene@orange.com Thu Jan 30 08:42:52 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAEF11A03E7 for ; Thu, 30 Jan 2014 08:42:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9t3OKvHIuqu3 for ; Thu, 30 Jan 2014 08:42:45 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 701F81A03FE for ; Thu, 30 Jan 2014 08:42:44 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 27AB818C480; Thu, 30 Jan 2014 17:42:40 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id EF4F94C0F6; Thu, 30 Jan 2014 17:42:39 +0100 (CET) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Thu, 30 Jan 2014 17:42:39 +0100 From: To: "Keyur Patel (keyupate)" Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPHcpH3MXmo8KxoESEhujQiGLM/ZqdXAiQ Date: Thu, 30 Jan 2014 16:42:39 +0000 Message-ID: <27511_1391100160_52EA8100_27511_13048_1_53C29892C857584299CBF5D05346208A070E05B8@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <22670_1391077677_52EA292D_22670_18044_1_53C29892C857584299CBF5D05346208A070E0357@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A070E05B8PEXCVZYM11corpo_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.30.152114 Cc: "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 16:42:52 -0000 --_000_53C29892C857584299CBF5D05346208A070E05B8PEXCVZYM11corpo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Keyur, Comments inlined #Bruno From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] Sent: Thursday, January 30, 2014 3:48 PM To: DECRAENE Bruno IMT/OLN Cc: idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Bruno, Comments Inlined #Keyur. From: > Date: Thu, 30 Jan 2014 10:27:56 +0000 To: Keyur Patel > Cc: "idr@ietf.org" > Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Keyur, Thanks for your reply. Your proposed new text, using NOTIFICATION only for syntax errors seems muc= h better to me. Thanks for the clarification. Ideally, in addition, I would prefer to have a text also covering other typ= es of errors. At least the violation of explicit statement in the draft. E.= g. for the following 2 MUST " Before the speaker starts a route refresh that is either initiated locally, or in response to a "normal route refresh request" from the peer, the speaker MUST send a BoRR message. After the speaker completes the re-advertisement of the entire Adj-RIB-Out to the peer, it MUST send an EoRR message." Regarding the first one, IMHO there is no harm if the MUST is not enforced.= One option may be :s/MUST/SHOULD; or a statement in =A7 "Error handling" o= n how to handle this error (e.g. log and nothing else). Regarding the second one, I'd like to see a text specifying what should be = done when I receive two BoRR. E.g. -a- consider that the second BoRR should be considered as a EoRR+ BoRR -b- ignore/abort the first EoRR procedure (i.e. remark all routes as STALE = when the second EoRR is received) -c- ignore the second EoRR. #Keyur: If the sender has sent two BoRRs (without an EoRR) then it means it= has aborted the first route refresh table announcement and restarted the r= oute refresh table announcement. The second EoRR will be essentially no-op = (I.e C case). Implementations can log the no-op behavior. #Bruno : well we don't really know what it means for the sender because it = was not supposed to do this in the first place, so it's a bug. Ok for your proposition to ignore the second EoRR. Would it be possible to = add this sentence/point in the =A7 "Error handling?" Especially since this = seems to contradict the spec which seems more on the side of "b": "When a BGP speaker receives a BoRR message from a peer, it MUST mark all the routes with the given from that peer as stale." Thanks, Regards, Bruno Regards, Keyur (plus obviously log the error in all cases) "a" sounds dangerous to me. "b" should a priori ok (accept a small error but consider that the speaker = remember (and acted as per) its latest message.) "c" is the safest path (there is a error, I don't know what it is so I take= the safest option) Considering the motivation for this draft (enhance BGP robustness, but not = bring a new feature), I think I would prefer "c" which is the more robust. = Especially given that if the receiver has a doubt, I has a way to clear it = by sending a new Route Refresh message. But I guess I would be fine with "b" if you/the WG have a different opinion. (My understanding of the current draft, is that "b" is expected, but in all= cases I would prefer a specific text in =A7 "Error handling") Thanks, Cheers, Bruno From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] Sent: Wednesday, January 29, 2014 11:16 PM To: DECRAENE Bruno IMT/OLN; Robert Raszuk Cc: idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Bruno, We only generate Notification for invalid length. Apologies for the confusi= on. Attached is the revised text. Regards, Keyur The error handling specified in this section is applicable only when a BGP speaker has received the "Enhanced Route Refresh Capability" from a peer. If the length, excluding the fixed-size message header, of the received ROUTE-REFRESH message with Message Subtype 1 and 2 is not 4, then the BGP speaker MUST send a NOTIFICATION message with the Error Code of "ROUTE-REFRESH Message Error" and the subcode of "Invalid Message Length". The Data field of the NOTIFICATION message MUST contain the complete ROUTE-REFRESH message. When the BGP speaker receives a ROUTE-REFRESH message with a "Message Subtype" field other than 1 or 2, it MUST ignore the received ROUTE- REFRESH message. It SHOULD log an error for further analysis. From: > Date: Wed, 29 Jan 2014 09:51:00 +0000 To: Robert Raszuk >, Keyur Pate= l > Cc: "idr@ietf.org" > Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi all, From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: Wednesday, January 29, 2014 10:15 AM To: Dongjie (Jimmy) Cc: Keyur Patel (keyupate); idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Jimmy and all, I think Enke and Keyur's proposed text with help from Jakob makes the behav= ior simplified and deterministic to hold on BoRR till first EoR is seen. IMHO it should be also spelled out what is the expected sequence error hand= ling here [Bruno] +1. And taking into account possible interaction with draft-ietf-i= dr-bgp-gr-notification BTW: "When the BGP speaker detects an error while processing a ROUTE-REFRESH mes= sage with a non-zero "Message Subtype" field, it MUST send a NOTIFICATION m= essage with Error Code "ROUTE-REFRESH Message Error"." Seems a priori not inline with the recommendation from draft-ietf-grow-ops-= reqs-for-bgp-error-handling (which is to limit the consequences of error ha= ndling). Are we sure that no error condition could be handled in a more fri= endly way? (e.g. if BoRR is not sent following a "normal route refresh requ= est" or if 2 BoRR are sent consecutively...) Thanks, Regards, Bruno ... I think not following "MUST NOT" shall implicitly result in entire sess= ion drop and complete restart ? Any error code ? Best, R. On Wed, Jan 29, 2014 at 9:22 AM, Dongjie (Jimmy) > wrote: Hi Robert, Agree that in these cases the RRQ cannot be ignored, so postpone may be a b= etter choice. While IMO stop the initial update and start over may delay the initial conv= ergence, and as you said it also relates to update group processing. What = do you think about the new text provided by Keyur? Best regards, Jie From:rraszuk@gmail.com [mailto:rraszuk@gmail.com<= mailto:rraszuk@gmail.com>] On Behalf Of Robert Raszuk Sent: Sunday, January 26, 2014 11:03 PM To: Dongjie (Jimmy) Cc: Keyur Patel (keyupate); Jakob Heitz; idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Jie, I think it actually very easy to say that initial update can not ever guara= ntee that RRQ received during its sending may meet the peer's need. Example 1: SAFI 128 - During receiving initial update from RR to PE new VRF got added = with new RT import. Unfortunately those updates received within initial upd= ate were already dropped as not interesting by the PE. RR must resend full = table after completed initial update. (Of course this is the case where the= re is no RTC and that's why RTC helps a lot here by incremental nature). Example 2: SAFI 1 - Operator has modified inbound policy on EBGP peer during processin= g of incoming updates and those originally were dropped. No soft reconfig i= n set. Conclusion: RRQ can not ever be ignored. Sure they can be delayed or batched (case of m= ultiple peers within the same update/peer group) sending near RRQs (cluster= of PEs got provisioned from central management station). But as Keyur alre= ady mentioned those are rather standard local implementation optimizations. Question: Does it maybe make sense to stop initial update when receiving RRQ from a p= eer and start over ? Of course if peer is part of large update group it wou= ld have to be removed dynamically from it so other members are not delayed.= In any case I think this does not impact the spec but the implementation. Cheers, R. On Sun, Jan 26, 2014 at 7:13 PM, Dongjie (Jimmy) > wrote: Hi Keyur, Jakob, Agree that "postpone" may be better. The point is we could avoid the compli= cated cases/considerations of performing route refresh during initial updat= e:) For "ignore", I was thinking of scenarios in which the route refresh requir= ement may already be met by the initial update, while I'd admit it is hard = to say... Best regards, Jie -----Original Message----- From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] Sent: Sunday, January 26, 2014 8:30 PM To: Jakob Heitz; Dongjie (Jimmy) Cc: idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Jie, I agree with Jakob. You could make it *an implementation behavior* to postp= one the route refresh reply. Regards, Keyur On 1/26/14 1:29 AM, "Jakob Heitz" > wrote: >You can definitely not ignore it, but you could postpone it. > >-- >Jakob Heitz. > >> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" > >>wrote: >> >> After reading the analyses in this thread, my personal feeling is >>maybe we should avoid the interleaving between GR initial update and >>route refresh/enhanced route refresh, since the initial update is just >>sending the whole Adj-RIB-Out, there is no obvious advantage to start >>a route refresh/enhance route refresh during it. So a speaker should >>ignore the RRQ received during the initial update. Thoughts? >> >> Best regards, >> Jie >> >> -----Original Message----- >> From: Idr [mailto:idr-bounces@ietf.org] On = Behalf Of Jakob Heitz >> Sent: Saturday, January 25, 2014 10:48 PM >> To: Chris Hall; idr@ietf.org >> Subject: Re: [Idr] WG LC for >> draft-ietf-idr-bgp-enhanced-route-refresh >> >> RFCs are written for coders "practiced" in the art". >> If anyone sends an EoRR before the adj-RIB-out is fully populated, >>then it's a BUG. >> This does not need to be said. >> >> Personally, I believe a route refresh request should not be honored >>until GR is complete. >> Also, I don't believe a timer for the receipt of EoRR is necessary, >>because the EoRR is guaranteed. >> Guaranteed means "unless the session drops first". >> -- >> >> Jakob Heitz. >> >> ________________________________________ >> From: Chris Hall [chris.hall@highwayman.com] >> Sent: Saturday, 25 January 2014 11:27 AM >> To: idr@ietf.org >> Cc: Jakob Heitz >> Subject: RE: [Idr] WG LC for >> draft-ietf-idr-bgp-enhanced-route-refresh >> >> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): >> ... >>> Silence means don't do it. >> >> Hmmm.... as a principle I'm more comfortable with "that which isn't >>prohibited is permitted".... >> >>> You would definitely NOT want BoRR to flush old stales. >> >> ....but, given the definite requirement, and given that the current >>precedent for "marking stale" does flush old stale, then a few words >>for the avoidance of doubt ? >> >>> Restarting the timer might be a good idea. >> >> I dunno... a route which remains stale for "a long time" is, of >>course, a candidate for being withdrawn: so having started a timer the >>first time things are set stale, I would avoid extending that -- at >>least for Graceful Restart, where the whole withdraw thing has been "on-h= old" >>since the last session failed. For route-refresh I guess there's more >>of a presumption that stale routes will be refreshed sooner or later, >>and in the meantime they remain good. So if the route-refresh is >>(repeatedly) restarted for some reason, perhaps it is more reasonable >>to extend the flush deadline -- but avoid doing this indefinitely ? >> >> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I have >>built in Quagga prioritise route changes (pending changes and any that >>occur during the refresh) over refresh updates. This makes it more >>likely that remaining stale routes are still good. But the other end >>cannot know that. >> >> The paragraph in the draft discussing the "entire Adj-RIB-Out" >>defines that to be the entries present "at the start of the route >>refresh operation", and observes that these comprise both reachable >>and unreachable routes. [An "of" after "comprise" sets teeth on edge, >>BTW.] I'm really not sure what this paragraph is trying to tell me. >> The reference to unreachable routes appears to suggest that pending >>withdraws should be sent as part of the refresh -- so not left to the >>EoRR to implement at the end. The point at which the EoRR is sent is >>defined such that it excludes any Adj-RIB-Out entries added after the >>route-refresh started, but includes any which are changed during the >>process. It seems reasonable to delay any brand new reachable >>prefixes until after all previously announced ones have been refreshed >>and the EoRR sent -- if that's the intent here. Changes which occur >>before the refresh gets to a given entry are pretty naturally swept up >>by the refresh. Changes which occur after the refresh has gone past, >>could/should be deferred to after the EoRR ? Does it make a >>difference if the change is a withdraw ? (Of course MRAI may kick in her= e. Ah. >>MRAI and route-refresh, there's a topic !) >> >> I think the essence of the rule is that the EoRR should be sent once >>all prefixes previously advertised to the peer as reachable have been >>refreshed, ie announced or withdrawn (at least) once. Or, perhaps >>more strictly, not *before* those prefixes have *all* been announced >>once -- given that the EoRR will promptly bang un-advertised stuff on the= head. >>Even more strictly perhaps: not send EoRR *before* any withdraws >>implied by it are required or desirable. >> >> Depending on the implementation, a given sender may or may not be >>able to determine the minimum set of updates required before sending EoRR. >> >> If the refresh operation takes a long time, there may be good >>routeing reasons to arrange for some route changes to be sent to the peer= "early" >>-- that is to send announcements which do not contribute to the >>refresh, but which are important enough to warrant delaying the end of >>the refresh. That could be a matter for recommendation(s) in the standar= d. >> >> NB: given that the timing of the EoRR is tied to the state of the >>Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. At >>the beginning of the initial update, the Restarting and Receiving >>speakers have: >> >> Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out >> >> Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In >> >> Now suppose (bonkers or otherwise) the receiving speaker sends an RRQ >>part way through the initial update. The restarting speaker responds >>with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specification. >> The receiving speaker sees the EoRR, and flushes stale. >>Unfortunately, if the restarting speaker has not yet fully populated >>its Adj-RIB-Out, then many further routes will be sent before the EoR >>falls due -- but the receiving speaker has already flushed their tiny >>posteriors :-( >> >> I am coming to the view that route-refresh during a Graceful Restart >>initial update is a horse of a different colour altogether. >> >> [So the assumption that EoRR and EoR are triggered by the same thing >>was completely wrong, and I apologise for it.] >> >> Chris >> >> _______________________________________________ >> 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 ___________________________________________________________________________= ______________________________________________ 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, 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 authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ 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, 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 authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ 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, 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 authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A070E05B8PEXCVZYM11corpo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

= Hi Keyur,

=  

= Comments inlined #Bruno=

=  

From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com]
Sent: Thursday, January 30, = 2014 3:48 PM
To: DECRAENE Bruno IMT/OLN Cc: idr@ietf.org
Subject: Re: [Idr] WG LC for= draft-ietf-idr-bgp-enhanced-route-refresh

 

Hi Bruno,

 

Comments Inlined #Keyur.

 

From: <bruno.de= craene@orange.com>
Date: Thu, 30 Jan 2014 10:27= :56 +0000
To: Keyur Patel <keyupate@cisco.com>
Cc: "idr@ietf.org" <id= r@ietf.org>
Subject: RE: [Idr] WG LC for= draft-ietf-idr-bgp-enhanced-route-refresh

 

= Hi Keyur,

=  

= Thanks for your reply.

= Your proposed new text, using NOT= IFICATION only for syntax errors seems much better to me. Thanks for the clarification.

=  

= Ideally, in addition, I would pre= fer to have a text also covering other types of errors. At least the violation of explicit statement in the draft. E.g. for the following 2= MUST<= /o:p>

“   Before the speaker starts a rout= e refresh that is either initiated

   locally, or in response to a "norm= al route refresh request" from the=

   peer, the speaker MUST send a B= oRR message.  After the speaker

   completes the re-advertisement of the e= ntire Adj-RIB-Out to the peer,

   it MUST send an = EoRR message.”

=  

= Regarding the first one, IMHO the= re is no harm if the MUST is not enforced. One option may be :s/MUST/SHOULD; or a statement in =A7 “Error handling” on how to handle this e= rror (e.g. log and nothing else).

= Regarding the second one, I’= ;d like to see a text specifying what should be done when I receive two BoRR. E.g.=

= -a- consider that the second BoRR= should be considered as a EoRR+ BoRR

= -b- ignore/abort the first EoRR p= rocedure (i.e. remark all routes as STALE when the second EoRR is received)<= o:p>

= -c- ignore the second EoRR.

=  

#Keyur: If the sender has sent two Bo= RRs (without an EoRR) then it means it has aborted the first route refresh table announcement and restarted the route refresh table announcem= ent. The second EoRR will be essentially no-op (I.e C case). Implementations can log the no-op behavior.=

= #Bruno : well we don’t= really know what it means for the sender because it was not supposed to do this in the first place, so it’s a bug.

Ok for your proposition to ignore the second EoRR. =
Would it be possible to add this sentence/point in the =A7 “Error han=
dling?” Especially since this seems to contradict the spec  whic=
h seems more on the side of “b”: “When

 = ;  a BGP speaker receives a BoRR message from a peer, it MUST mark all=

 = ;  the routes with the given <AFI, SAFI> from that peer as stale= .”

= Thanks,<= /p>

= Regards,=

= Bruno 

 

Regards,

Keyur

 

= (plus obviously log the error in = all cases)

=  

= “a” sounds dangerous = to me.

= “b” should a priori o= k (accept a small error but consider that the speaker remember (and acted as per) its latest message.)

= “c” is the safest pat= h (there is a error, I don’t know what it is so I take the safest opt= ion)

=  

= Considering the motivation for th= is draft (enhance BGP robustness, but not bring a new feature), I think I would prefer “c” which is the more robust. Especiall= y given that if the receiver has a doubt, I has a way to clear it by sendin= g a new Route Refresh message.

= But I guess I would be fine with = “b” if you/the WG have a different opinion.

= (My understanding of the current = draft, is that “b” is expected, but in all cases I would prefer a specific text in  =A7 “Error handling”)

=  

= Thanks,

= Cheers,

= Bruno

=  

=  

= From: Keyur Patel (keyupate) [mailto:keyup= ate@cisco.com]
Sent: Wednesday, January 29,= 2014 11:16 PM
To: DECRAENE Bruno IMT/OLN; = Robert Raszuk
Cc: idr@ietf.org
Subject: Re: [Idr] WG LC for= draft-ietf-idr-bgp-enhanced-route-refresh

 =

Hi Bruno,

 

We only generate Notification for invalid length. Ap= ologies for the confusion. Attached is the revised text.

 

Regards,

Keyur

 

<snip>

The error handling specified in this section is appl= icable only when

   a BGP speaker has received the "En= hanced Route Refresh Capability"

   from a peer.

 

   If the length, excluding the fixed-size= message header, of the

   received ROUTE-REFRESH message with Mes= sage Subtype 1 and 2 is not 4,

   then the BGP speaker MUST send a NOTIFI= CATION message with the Error

   Code of "ROUTE-REFRESH Message Err= or" and the subcode of "Invalid

   Message Length".  The Data fi= eld of the NOTIFICATION message MUST

   contain the complete ROUTE-REFRESH mess= age.

 

   When the BGP speaker receives a ROUTE-R= EFRESH message with a "Message

   Subtype" field other than 1 or 2, = it MUST ignore the received ROUTE-

   REFRESH message.  It SHOULD log an= error for further analysis.

 

<snip>

 

From: <bruno.de= craene@orange.com>
Date: Wed, 29 Jan 2014 09:51= :00 +0000
To: Robert Raszuk <robert@raszuk.net>, Keyur Patel <<= a href=3D"mailto:keyupate@cisco.com">keyupate@cisco.com>
Cc: "idr@ietf.org" <id= r@ietf.org>
Subject: RE: [Idr] WG LC for= draft-ietf-idr-bgp-enhanced-route-refresh

 

= Hi all,

=  

=  

 

Hi Jimmy and all,

 

I think Enke and Keyur's proposed text with help from Jakob makes t= he behavior simplified and deterministic to hold on BoRR till first EoR is seen.

 

IMHO it should be also spelled out what is the expected sequence er= ror handling here =

=  

= [Bruno] +1.  And taking = into account possible interaction with draft-ietf-idr-bgp-gr-notification

=  

= BTW:

= “When the BGP speaker detec= ts an error while processing a ROUTE-REFRESH message with a non-zero "= Message Subtype" field, it MUST send a NOTIFICATION message with Error Code &= quot;ROUTE-REFRESH Message Error".”

=  

= Seems a priori not inline with th= e recommendation from draft-ietf-grow-ops-reqs-for-bgp-error-handling (which is to limit the consequences of error handling). Are we sure that n= o error condition could be handled in a more friendly way? (e.g. if BoRR is= not sent following a “normal route refresh request” or if 2 Bo= RR are sent consecutively…)

=  

= Thanks,

= Regards,

= Bruno

=  

=  

... I think not following "M= UST NOT" shall implicitly result in entire session drop and complete r= estart ? Any error code ?

 

Best,
R.

 

 

On Wed, Jan 29, 2014 at = 9:22 AM, Dongjie (Jimmy) <jie.dong@huawei.com> wrote:

Hi Robert, =

 

Agree that in these cases the RRQ cannot be ignored, so postpone may be a better choice.

 

While IMO stop the initial update and start over may delay the initial convergence, and as you said  it als= o relates to update group processing. What do you think about the new text = provided by Keyur? =

 

Best regards,

Jie

 

From:rraszuk@gmail.com= [mailto:rraszuk@gma= il.com] On Behalf Of Robert Raszuk Sent: Sunday, January 26, 20= 14 11:03 PM
To: Dongjie (Jimmy)
Cc: Keyur Patel (keyupate); = Jakob Heitz; idr@ietf.org


Subject: Re: [Idr] WG LC for= draft-ietf-idr-bgp-enhanced-route-refresh

 

Hi Jie,

 

I think it actually very easy to say that initial update can not ever guarantee that RRQ received during its sending may mee= t the peer's need.

 

Example 1:

 

SAFI 128 - During receiving initial update from RR to PE new VRF got added with new RT import. Unfortunately those updates= received within initial update were already dropped as not interesting by = the PE. RR must resend full table after completed initial update. (Of cours= e this is the case where there is no RTC and that's why RTC helps a lot here by incremental nature). 

 

Example 2: 

 

SAFI 1 - Operator has modified inbound policy on EBGP peer during processing of incoming updates and those originally were = dropped. No soft reconfig in set. =

 

Conclusion:

 

RRQ can not ever be ignored. Sure they can be delayed or batched (case of multiple peers within the same update/peer group) send= ing near RRQs (cluster of PEs got provisioned from central management stati= on). But as Keyur already mentioned those are rather standard local impleme= ntation optimizations. 

 

Question:

 

Does it maybe make sense to stop initial update when receiving RRQ from a peer and start over ? Of course if peer is part = of large update group it would have to be removed dynamically from it so ot= her members are not delayed. In any case I think this does not impact the s= pec but the implementation.

 

Cheers,
R.

 

 

 

On Sun, Jan 26, 2014 at= 7:13 PM, Dongjie (Jimmy) <jie.dong@huawei.com> wrote:

Hi Keyur, Jakob,

Agree that "postpone" may be better. The point is we could avoid = the complicated cases/considerations of performing route refresh during ini= tial update:)

For "ignore", I was thinking of scenarios in which the route refr= esh requirement may already be met by the initial update, while I'd admit i= t is hard to say...



Best regards,
Jie

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

From: Keyur Patel (keyu= pate) [mailto:keyup= ate@cisco.com]
Sent: Sunday, January 26, 2014 8:30 PM
To: Jakob Heitz; Dongjie (Jimmy)
Cc: idr@ietf.org
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Jie,

I agree with Jakob. You could make it *an implementation behavior* to postp= one the route refresh reply.


Regards,
Keyur

On 1/26/14 1:29 AM, "Jakob Heitz" <jakob.heitz@ericsson.com> wrote:<= br>
>You can definitely not ignore it, but you could postpone it.
>
>--
>Jakob Heitz.
>
>> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" <jie.dong@huawei.com>
>>wrote:
>>
>> After reading the analyses in this thread, my personal feeling is<= br> >>maybe we should avoid the interleaving between GR initial update an= d
>>route refresh/enhanced route refresh, since the initial update is j= ust
>>sending the whole Adj-RIB-Out, there is no obvious advantage to sta= rt
>>a route refresh/enhance route refresh during it. So a speaker shoul= d
>>ignore the RRQ received during the initial update. Thoughts?
>>
>> Best regards,
>> Jie
>>
>> -----Original Message-----
>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz
>> Sent: Saturday, January 25, 2014 10:48 PM
>> To: Chris Hall; = idr@ietf.org
>> Subject: Re: [Idr] WG LC for
>> draft-ietf-idr-bgp-enhanced-route-refresh
>>
>> RFCs are written for coders "practiced" in the art"= .
>> If anyone sends an EoRR before the adj-RIB-out is fully populated,=
>>then it's a BUG.
>> This does not need to be said.
>>
>> Personally, I believe a route refresh request should not be honore= d
>>until GR is complete.
>> Also, I don't believe a timer for the receipt of EoRR is necessary= ,
>>because the EoRR is guaranteed.
>> Guaranteed means "unless the session drops first".
>> --
>>
>> Jakob Heitz.
>>
>> ________________________________________
>> From: Chris Hall [chris.hall@highwayman.com]
>> Sent: Saturday, 25 January 2014 11:27 AM
>> To: idr@ietf.org=
>> Cc: Jakob Heitz
>> Subject: RE: [Idr] WG LC for
>> draft-ietf-idr-bgp-enhanced-route-refresh
>>
>> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37):
>> ...
>>> Silence means don't do it.
>>
>> Hmmm.... as a principle I'm more comfortable with "that which= isn't
>>prohibited is permitted"....
>>
>>> You would definitely NOT want BoRR to flush old stales.
>>
>> ....but, given the definite requirement, and given that the curren= t
>>precedent for "marking stale" does flush old stale, then = a few words
>>for the avoidance of doubt ?
>>
>>> Restarting the timer might be a good idea.
>>
>> I dunno... a route which remains stale for "a long time"= is, of
>>course, a candidate for being withdrawn: so having started a timer = the
>>first time things are set stale, I would avoid extending that -- at=
>>least for Graceful Restart, where the whole withdraw thing has been= "on-hold"
>>since the last session failed.  For route-refresh I guess ther= e's more
>>of a presumption that stale routes will be refreshed sooner or late= r,
>>and in the meantime they remain good.  So if the route-refresh= is
>>(repeatedly) restarted for some reason, perhaps it is more reasonab= le
>>to extend the flush deadline -- but avoid doing this indefinitely ?=
>>
>> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I ha= ve
>>built in Quagga prioritise route changes (pending changes and any t= hat
>>occur during the refresh) over refresh updates.  This makes it= more
>>likely that remaining stale routes are still good.  But the ot= her end
>>cannot know that.
>>
>> The paragraph in the draft discussing the "entire Adj-RIB-Out= "
>>defines that to be the entries present "at the start of the ro= ute
>>refresh operation", and observes that these comprise both reac= hable
>>and unreachable routes.  [An "of" after "compri= se" sets teeth on edge,
>>BTW.]  I'm really not sure what this paragraph is trying to te= ll me.
>> The reference to unreachable routes appears to suggest that pendin= g
>>withdraws should be sent as part of the refresh -- so not left to t= he
>>EoRR to implement at the end.  The point at which the EoRR is = sent is
>>defined such that it excludes any Adj-RIB-Out entries added after t= he
>>route-refresh started, but includes any which are changed during th= e
>>process.  It seems reasonable to delay any brand new reachable=
>>prefixes until after all previously announced ones have been refres= hed
>>and the EoRR sent -- if that's the intent here.  Changes which= occur
>>before the refresh gets to a given entry are pretty naturally swept= up
>>by the refresh.  Changes which occur after the refresh has gon= e past,
>>could/should be deferred to after the EoRR ?  Does it make a >>difference if the change is a withdraw ?  (Of course MRAI may = kick in here.  Ah.
>>MRAI and route-refresh, there's a topic !)
>>
>> I think the essence of the rule is that the EoRR should be sent on= ce
>>all prefixes previously advertised to the peer as reachable have be= en
>>refreshed, ie announced or withdrawn (at least) once.  Or, per= haps
>>more strictly, not *before* those prefixes have *all* been announce= d
>>once -- given that the EoRR will promptly bang un-advertised stuff = on the head.
>>Even more strictly perhaps: not send EoRR *before* any withdraws
>>implied by it are required or desirable.
>>
>> Depending on the implementation, a given sender may or may not be<= br> >>able to determine the minimum set of updates required before sendin= g EoRR.
>>
>> If the refresh operation takes a long time, there may be good
>>routeing reasons to arrange for some route changes to be sent to th= e peer "early"
>>-- that is to send announcements which do not contribute to the
>>refresh, but which are important enough to warrant delaying the end= of
>>the refresh.  That could be a matter for recommendation(s) in = the standard.
>>
>> NB: given that the timing of the EoRR is tied to the state of the<= br> >>Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. &= nbsp;At
>>the beginning of the initial update, the Restarting and Receiving >>speakers have:
>>
>>  Restarting:  Empty Adj-RIB-In   Empty Adj-RIB-Out<= br> >>
>>  Receiving:   Empty Adj-RIB-Out  Stale Adj-RIB-In >>
>> Now suppose (bonkers or otherwise) the receiving speaker sends an = RRQ
>>part way through the initial update.  The restarting speaker r= esponds
>>with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specifica= tion.
>> The receiving speaker sees the EoRR, and flushes stale.
>>Unfortunately, if the restarting speaker has not yet fully populate= d
>>its Adj-RIB-Out, then many further routes will be sent before the E= oR
>>falls due -- but the receiving speaker has already flushed their ti= ny
>>posteriors :-(
>>
>> I am coming to the view that route-refresh during a Graceful Resta= rt
>>initial update is a horse of a different colour altogether.
>>
>> [So the assumption that EoRR and EoR are triggered by the same thi= ng
>>was completely wrong, and I apologise for it.]
>>
>> Chris
>>
>> _______________________________________________
>> 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
htt= ps://www.ietf.org/mailman/listinfo/idr

 

 = 

______________________________________________=
___________________________________________________________________________=

 
Ce message et ses pieces jointes peuvent conte=
nir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans au=
torisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pi=
eces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce mess=
age a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain c=
onfidential or privileged information that may be protected by law;
they should not be distributed, used or copied=
 without authorisation.
If you have received this email in error, plea=
se notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable=
 for messages that have been modified, changed or falsified.
Thank you.
______________________________________________=
___________________________________________________________________________=

 
Ce message et ses pieces jointes peuvent conte=
nir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans au=
torisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pi=
eces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce mess=
age a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain c=
onfidential or privileged information that may be protected by law;
they should not be distributed, used or copied=
 without authorisation.
If you have received this email in error, plea=
se notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable=
 for messages that have been modified, changed or falsified.
Thank you.
______________________________________________________________________=
___________________________________________________

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,
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 authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A070E05B8PEXCVZYM11corpo_-- From chris.hall@highwayman.com Thu Jan 30 09:05:59 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 430391A041B for ; Thu, 30 Jan 2014 09:05:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.16 X-Spam-Level: X-Spam-Status: No, score=0.16 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-NtDl9BYLZ3 for ; Thu, 30 Jan 2014 09:05:57 -0800 (PST) Received: from smtp.demon.co.uk (mdfmta005.mxout.tbr.inty.net [91.221.168.46]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0ED1A0417 for ; Thu, 30 Jan 2014 09:05:57 -0800 (PST) Received: from mdfmta005.tbr.inty.net (unknown [127.0.0.1]) by mdfmta005.tbr.inty.net (Postfix) with ESMTP id 952AB6A8011 for ; Thu, 30 Jan 2014 17:05:53 +0000 (GMT) Received: from mdfmta005.tbr.inty.net (unknown [127.0.0.1]) by mdfmta005.tbr.inty.net (Postfix) with ESMTP id 7116CA6478E for ; Thu, 30 Jan 2014 17:05:53 +0000 (GMT) Received: from hestia.halldom.com (unknown [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta005.tbr.inty.net (Postfix) with ESMTP for ; Thu, 30 Jan 2014 17:05:53 +0000 (GMT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by hestia.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1W8v3o-0007M2-Ey for idr@ietf.org; Thu, 30 Jan 2014 17:05:52 +0000 From: "Chris Hall" To: References: <6650_1390989061_52E8CF05_6650_399_1_53C29892C857584299CBF5D05346208A070DFED8@PEXCVZYM11.corporate.adroot.infra.ftgroup> <22670_1391077677_52EA292D_22670_18044_1_53C29892C857584299CBF5D05346208A070E0357@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <22670_1391077677_52EA292D_22670_18044_1_53C29892C857584299CBF5D05346208A070E0357@PEXCVZYM11.corporate.adroot.infra.ftgroup> Date: Thu, 30 Jan 2014 17:05:46 -0000 Organization: Highwayman Message-ID: <0c9a01cf1ddd$881047e0$9830d7a0$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJczIeCZwOCTimw69CgoSMR5DnV+AJ9P6I3AohiFhqZWaRD0A== Content-Language: en-gb X-MDF-HostID: 8 Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 17:05:59 -0000 Bruno Decraene wrote (on Thu 30-Jan-2014 at 10:28 +0000): .... > Regarding the second one, I=92d like to see a text specifying what > should be done when I receive two BoRR. E.g. In the (however unlikely) case of both ends deciding to trigger a route-refresh at roughly the same time, it is possible for a BoRR and an RRQ (route-refresh-request) to cross. By rule, a BoRR must be sent in response to RRQ: starting or _restarting_ route-refresh. So, a second BoRR is not necessarily an error, at least after sending RRQ. Moreover, as I understand it, the intention is that either end can not only start but also restart a route-refresh, at any time. Which makes two (or more) BoRR without an intervening EoRR, by definition, OK. Further, as I understand it, a refresh operation may be restarted any number of times, sending BoRR any number of times, terminated by a single EoRR. Now, by way of an exception, we have GR Initial Update "mode". This looks much as if the two ends have sent each other a "virtual BoRR", to be terminated by an actual EoR. But, in this case, if either end sends an RRQ, the plan is for the other to hold up the BoRR response until after the EoR is sent. And (I assume) if either feels moved to do a route-refresh during the Initial Update, it must hold in the BoRR until after the EoR -- making BoRR before EoR an error. [Both ends could be required to hold in an RRQ until after EoR... but I'm not sure where the rules are stating the expected/proper behaviour, and where they are intended to "just work" for both expected and unexpected/improper messages. I guess it's "obvious" that multiple RRQs can be responded to by one BoRR ?] Just exploring the possibilities... I suppose this approach could be extended to route-refresh: so that after BoRR and before EoRR, the sender holds up an incoming RRQ, and holds in any impulse to restart the route-refresh itself. So that: * BoRR and EoRR would, indeed, be brackets. As you say, this would imply some to-be-defined error=20 handling for BoRR during route-refresh or during GR=20 Initial Update -- in addition to the error handling for=20 EoRR not during route-refresh. [I guess the error=20 handling for an unexpected EoR is to ignore it.] * if either end were to decide that a route-refresh was required part way through an existing route-refresh or=20 an initial update, then everything sent from that moment up to the EoRR/EoR would be a waste of time and effort. On the other hand, it would also mean that a route- refresh and initial update could not be endlessly=20 extended by repeated BoRR/RRQ. * the handling of route-refresh and initial update would be consistent -- for what that's worth. FWIW: I think that when a route-refresh is required, it should be started as soon as possible. Suppose an initial update is half way through sending 300,000 routes, and a route-refresh becomes needed: holding up the refresh until after the EoR means that 150,000 routes will be repeated, unnecessarily. At the Restarting Speaker end, delaying EoR may delay route-selection. On the other hand, if the route-refresh is delayed and starts immediately after the EoR, route-selection starts with 300,000 stale routes on its hands. You win some, you lose some... but on balance, ploughing on with a route-refresh or initial update, when a new route-refresh is required, feels wrong to me. However, these cases are screamingly unlikely, so provided that the eventualities are clearly covered -- requiring the minimum of extra mechanism and/or error handling (code) -- the price of cocoa is unaffected. Chris From jakob.heitz@ericsson.com Thu Jan 30 09:26:25 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340FB1A03FD for ; Thu, 30 Jan 2014 09:26:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fK_8Bh6vU-lv for ; Thu, 30 Jan 2014 09:26:18 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id AF3E01A03C7 for ; Thu, 30 Jan 2014 09:26:17 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-ab-52ea8b32c536 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 16.83.12743.23B8AE25; Thu, 30 Jan 2014 18:26:11 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0387.000; Thu, 30 Jan 2014 12:26:13 -0500 From: Jakob Heitz To: "bruno.decraene@orange.com" Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPF5KdKHMolEg8TF26AxOKep0T6JqRMOhAgAGfMAD//7gu+4AAX1gA//+1BTCAAHhgAP//sQGgAA5+ToAABygAoAAmsOcAAAoIr7AAJlf4AP//r6/0gAEnPAD//8BcWoAA2iqAgAAMEwCAAB6LgIAD81WAgAAOsoCAAAoOAIAA0CeAgADMfwCAAEiuAIAAIASA//+4WTM= Date: Thu, 30 Jan 2014 17:26:12 +0000 Message-ID: <5EECE2EC-9406-4BDB-8AEB-ADD1B7ABB167@ericsson.com> References: <22670_1391077677_52EA292D_22670_18044_1_53C29892C857584299CBF5D05346208A070E0357@PEXCVZYM11.corporate.adroot.infra.ftgroup> , <27511_1391100160_52EA8100_27511_13048_1_53C29892C857584299CBF5D05346208A070E05B8@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <27511_1391100160_52EA8100_27511_13048_1_53C29892C857584299CBF5D05346208A070E05B8@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_5EECE2EC94064BDB8AEBADD1B7ABB167ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUyuXRPgq5x96sgg6OX+Sx+7JjDbPHq9jMm i8at59kcmD2m/N7I6rFkyU8mj5ZnJ9kCmKO4bFJSczLLUov07RK4MhqW6RQcnsJWMaOzlbmB cfNe1i5GTg4JAROJOW3NLBC2mMSFe+vZuhi5OIQEjjBKTNw6C8pZziix5XwfI0gVm4COxLfr XcwgtoiAtcSDiSAdnBzMAkESB/bvYAexhQXcJF5NWs4OUeMu0fJjEjPIIBGBW4wS85/0MIEk WARUJbZMOwA2iFfAXuJueyszxLbVTBLf1lxnB3E4BToZJTZ+nwt2ICPQgd9PrWGCWCcucevJ fCaIwwUkluw5zwxhi0q8fPyPFaImWeLipN9sEBsEJU7OfMIygVFkFpL2WUjKZiEpg4gbSLw/ N58ZwtaWWLbwNZStL7Hxy1lGZPEFjOyrGDlKi1PLctONDDYxAmPrmASb7g7GPS8tDzFKc7Ao ifN+eescJCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFxi0R1LfuUiQtW6cwXPL/8zCzzMCb5 xMZYO1lF522TxK6JfQk+eX/NZtm35nJ1FofPWt0pkTkiZim0XSk11aQpxGaR/O49Zw4Fb1B2 +hmuK+i37eP6+/dcWO+pWKhYJ/2qeuW5x/iPZZzDs1kML/I/bXzP+VV5wSGmVZ98dS000/Vn /p+62XCTEktxRqKhFnNRcSIA4T4fw3sCAAA= Cc: "Keyur Patel \(keyupate\)" , "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 17:26:25 -0000 --_000_5EECE2EC94064BDB8AEBADD1B7ABB167ericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Then make it not a bug. A second BoRR means the first one was aborted. The draft as it stands alrea= dy covers this case. -- Jakob Heitz. On Jan 30, 2014, at 8:43 AM, "bruno.decraene@orange.com" > wrote: Hi Keyur, Comments inlined #Bruno From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] Sent: Thursday, January 30, 2014 3:48 PM To: DECRAENE Bruno IMT/OLN Cc: idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Bruno, Comments Inlined #Keyur. From: > Date: Thu, 30 Jan 2014 10:27:56 +0000 To: Keyur Patel > Cc: "idr@ietf.org" > Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Keyur, Thanks for your reply. Your proposed new text, using NOTIFICATION only for syntax errors seems muc= h better to me. Thanks for the clarification. Ideally, in addition, I would prefer to have a text also covering other typ= es of errors. At least the violation of explicit statement in the draft. E.= g. for the following 2 MUST =93 Before the speaker starts a route refresh that is either initiated locally, or in response to a "normal route refresh request" from the peer, the speaker MUST send a BoRR message. After the speaker completes the re-advertisement of the entire Adj-RIB-Out to the peer, it MUST send an EoRR message.=94 Regarding the first one, IMHO there is no harm if the MUST is not enforced.= One option may be :s/MUST/SHOULD; or a statement in =A7 =93Error handling= =94 on how to handle this error (e.g. log and nothing else). Regarding the second one, I=92d like to see a text specifying what should b= e done when I receive two BoRR. E.g. -a- consider that the second BoRR should be considered as a EoRR+ BoRR -b- ignore/abort the first EoRR procedure (i.e. remark all routes as STALE = when the second EoRR is received) -c- ignore the second EoRR. #Keyur: If the sender has sent two BoRRs (without an EoRR) then it means it= has aborted the first route refresh table announcement and restarted the r= oute refresh table announcement. The second EoRR will be essentially no-op = (I.e C case). Implementations can log the no-op behavior. #Bruno : well we don=92t really know what it means for the sender because i= t was not supposed to do this in the first place, so it=92s a bug. Ok for your proposition to ignore the second EoRR. Would it be possible to = add this sentence/point in the =A7 =93Error handling?=94 Especially since t= his seems to contradict the spec which seems more on the side of =93b=94: = =93When a BGP speaker receives a BoRR message from a peer, it MUST mark all the routes with the given from that peer as stale.=94 Thanks, Regards, Bruno Regards, Keyur (plus obviously log the error in all cases) =93a=94 sounds dangerous to me. =93b=94 should a priori ok (accept a small error but consider that the spea= ker remember (and acted as per) its latest message.) =93c=94 is the safest path (there is a error, I don=92t know what it is so = I take the safest option) Considering the motivation for this draft (enhance BGP robustness, but not = bring a new feature), I think I would prefer =93c=94 which is the more robu= st. Especially given that if the receiver has a doubt, I has a way to clear= it by sending a new Route Refresh message. But I guess I would be fine with =93b=94 if you/the WG have a different opi= nion. (My understanding of the current draft, is that =93b=94 is expected, but in= all cases I would prefer a specific text in =A7 =93Error handling=94) Thanks, Cheers, Bruno From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] Sent: Wednesday, January 29, 2014 11:16 PM To: DECRAENE Bruno IMT/OLN; Robert Raszuk Cc: idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Bruno, We only generate Notification for invalid length. Apologies for the confusi= on. Attached is the revised text. Regards, Keyur The error handling specified in this section is applicable only when a BGP speaker has received the "Enhanced Route Refresh Capability" from a peer. If the length, excluding the fixed-size message header, of the received ROUTE-REFRESH message with Message Subtype 1 and 2 is not 4, then the BGP speaker MUST send a NOTIFICATION message with the Error Code of "ROUTE-REFRESH Message Error" and the subcode of "Invalid Message Length". The Data field of the NOTIFICATION message MUST contain the complete ROUTE-REFRESH message. When the BGP speaker receives a ROUTE-REFRESH message with a "Message Subtype" field other than 1 or 2, it MUST ignore the received ROUTE- REFRESH message. It SHOULD log an error for further analysis. From: > Date: Wed, 29 Jan 2014 09:51:00 +0000 To: Robert Raszuk >, Keyur Pate= l > Cc: "idr@ietf.org" > Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi all, From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: Wednesday, January 29, 2014 10:15 AM To: Dongjie (Jimmy) Cc: Keyur Patel (keyupate); idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Jimmy and all, I think Enke and Keyur's proposed text with help from Jakob makes the behav= ior simplified and deterministic to hold on BoRR till first EoR is seen. IMHO it should be also spelled out what is the expected sequence error hand= ling here [Bruno] +1. And taking into account possible interaction with draft-ietf-i= dr-bgp-gr-notification BTW: =93When the BGP speaker detects an error while processing a ROUTE-REFRESH m= essage with a non-zero "Message Subtype" field, it MUST send a NOTIFICATION= message with Error Code "ROUTE-REFRESH Message Error".=94 Seems a priori not inline with the recommendation from draft-ietf-grow-ops-= reqs-for-bgp-error-handling (which is to limit the consequences of error ha= ndling). Are we sure that no error condition could be handled in a more fri= endly way? (e.g. if BoRR is not sent following a =93normal route refresh re= quest=94 or if 2 BoRR are sent consecutively=85) Thanks, Regards, Bruno ... I think not following "MUST NOT" shall implicitly result in entire sess= ion drop and complete restart ? Any error code ? Best, R. On Wed, Jan 29, 2014 at 9:22 AM, Dongjie (Jimmy) > wrote: Hi Robert, Agree that in these cases the RRQ cannot be ignored, so postpone may be a b= etter choice. While IMO stop the initial update and start over may delay the initial conv= ergence, and as you said it also relates to update group processing. What = do you think about the new text provided by Keyur? Best regards, Jie From:rraszuk@gmail.com [mailto:rraszuk@gmail.com<= mailto:rraszuk@gmail.com>] On Behalf Of Robert Raszuk Sent: Sunday, January 26, 2014 11:03 PM To: Dongjie (Jimmy) Cc: Keyur Patel (keyupate); Jakob Heitz; idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Jie, I think it actually very easy to say that initial update can not ever guara= ntee that RRQ received during its sending may meet the peer's need. Example 1: SAFI 128 - During receiving initial update from RR to PE new VRF got added = with new RT import. Unfortunately those updates received within initial upd= ate were already dropped as not interesting by the PE. RR must resend full = table after completed initial update. (Of course this is the case where the= re is no RTC and that's why RTC helps a lot here by incremental nature). Example 2: SAFI 1 - Operator has modified inbound policy on EBGP peer during processin= g of incoming updates and those originally were dropped. No soft reconfig i= n set. Conclusion: RRQ can not ever be ignored. Sure they can be delayed or batched (case of m= ultiple peers within the same update/peer group) sending near RRQs (cluster= of PEs got provisioned from central management station). But as Keyur alre= ady mentioned those are rather standard local implementation optimizations. Question: Does it maybe make sense to stop initial update when receiving RRQ from a p= eer and start over ? Of course if peer is part of large update group it wou= ld have to be removed dynamically from it so other members are not delayed.= In any case I think this does not impact the spec but the implementation. Cheers, R. On Sun, Jan 26, 2014 at 7:13 PM, Dongjie (Jimmy) > wrote: Hi Keyur, Jakob, Agree that "postpone" may be better. The point is we could avoid the compli= cated cases/considerations of performing route refresh during initial updat= e:) For "ignore", I was thinking of scenarios in which the route refresh requir= ement may already be met by the initial update, while I'd admit it is hard = to say... Best regards, Jie -----Original Message----- From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] Sent: Sunday, January 26, 2014 8:30 PM To: Jakob Heitz; Dongjie (Jimmy) Cc: idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Jie, I agree with Jakob. You could make it *an implementation behavior* to postp= one the route refresh reply. Regards, Keyur On 1/26/14 1:29 AM, "Jakob Heitz" > wrote: >You can definitely not ignore it, but you could postpone it. > >-- >Jakob Heitz. > >> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" > >>wrote: >> >> After reading the analyses in this thread, my personal feeling is >>maybe we should avoid the interleaving between GR initial update and >>route refresh/enhanced route refresh, since the initial update is just >>sending the whole Adj-RIB-Out, there is no obvious advantage to start >>a route refresh/enhance route refresh during it. So a speaker should >>ignore the RRQ received during the initial update. Thoughts? >> >> Best regards, >> Jie >> >> -----Original Message----- >> From: Idr [mailto:idr-bounces@ietf.org] On = Behalf Of Jakob Heitz >> Sent: Saturday, January 25, 2014 10:48 PM >> To: Chris Hall; idr@ietf.org >> Subject: Re: [Idr] WG LC for >> draft-ietf-idr-bgp-enhanced-route-refresh >> >> RFCs are written for coders "practiced" in the art". >> If anyone sends an EoRR before the adj-RIB-out is fully populated, >>then it's a BUG. >> This does not need to be said. >> >> Personally, I believe a route refresh request should not be honored >>until GR is complete. >> Also, I don't believe a timer for the receipt of EoRR is necessary, >>because the EoRR is guaranteed. >> Guaranteed means "unless the session drops first". >> -- >> >> Jakob Heitz. >> >> ________________________________________ >> From: Chris Hall [chris.hall@highwayman.com] >> Sent: Saturday, 25 January 2014 11:27 AM >> To: idr@ietf.org >> Cc: Jakob Heitz >> Subject: RE: [Idr] WG LC for >> draft-ietf-idr-bgp-enhanced-route-refresh >> >> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): >> ... >>> Silence means don't do it. >> >> Hmmm.... as a principle I'm more comfortable with "that which isn't >>prohibited is permitted".... >> >>> You would definitely NOT want BoRR to flush old stales. >> >> ....but, given the definite requirement, and given that the current >>precedent for "marking stale" does flush old stale, then a few words >>for the avoidance of doubt ? >> >>> Restarting the timer might be a good idea. >> >> I dunno... a route which remains stale for "a long time" is, of >>course, a candidate for being withdrawn: so having started a timer the >>first time things are set stale, I would avoid extending that -- at >>least for Graceful Restart, where the whole withdraw thing has been "on-h= old" >>since the last session failed. For route-refresh I guess there's more >>of a presumption that stale routes will be refreshed sooner or later, >>and in the meantime they remain good. So if the route-refresh is >>(repeatedly) restarted for some reason, perhaps it is more reasonable >>to extend the flush deadline -- but avoid doing this indefinitely ? >> >> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I have >>built in Quagga prioritise route changes (pending changes and any that >>occur during the refresh) over refresh updates. This makes it more >>likely that remaining stale routes are still good. But the other end >>cannot know that. >> >> The paragraph in the draft discussing the "entire Adj-RIB-Out" >>defines that to be the entries present "at the start of the route >>refresh operation", and observes that these comprise both reachable >>and unreachable routes. [An "of" after "comprise" sets teeth on edge, >>BTW.] I'm really not sure what this paragraph is trying to tell me. >> The reference to unreachable routes appears to suggest that pending >>withdraws should be sent as part of the refresh -- so not left to the >>EoRR to implement at the end. The point at which the EoRR is sent is >>defined such that it excludes any Adj-RIB-Out entries added after the >>route-refresh started, but includes any which are changed during the >>process. It seems reasonable to delay any brand new reachable >>prefixes until after all previously announced ones have been refreshed >>and the EoRR sent -- if that's the intent here. Changes which occur >>before the refresh gets to a given entry are pretty naturally swept up >>by the refresh. Changes which occur after the refresh has gone past, >>could/should be deferred to after the EoRR ? Does it make a >>difference if the change is a withdraw ? (Of course MRAI may kick in her= e. Ah. >>MRAI and route-refresh, there's a topic !) >> >> I think the essence of the rule is that the EoRR should be sent once >>all prefixes previously advertised to the peer as reachable have been >>refreshed, ie announced or withdrawn (at least) once. Or, perhaps >>more strictly, not *before* those prefixes have *all* been announced >>once -- given that the EoRR will promptly bang un-advertised stuff on the= head. >>Even more strictly perhaps: not send EoRR *before* any withdraws >>implied by it are required or desirable. >> >> Depending on the implementation, a given sender may or may not be >>able to determine the minimum set of updates required before sending EoRR= . >> >> If the refresh operation takes a long time, there may be good >>routeing reasons to arrange for some route changes to be sent to the peer= "early" >>-- that is to send announcements which do not contribute to the >>refresh, but which are important enough to warrant delaying the end of >>the refresh. That could be a matter for recommendation(s) in the standar= d. >> >> NB: given that the timing of the EoRR is tied to the state of the >>Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. At >>the beginning of the initial update, the Restarting and Receiving >>speakers have: >> >> Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out >> >> Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In >> >> Now suppose (bonkers or otherwise) the receiving speaker sends an RRQ >>part way through the initial update. The restarting speaker responds >>with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specification. >> The receiving speaker sees the EoRR, and flushes stale. >>Unfortunately, if the restarting speaker has not yet fully populated >>its Adj-RIB-Out, then many further routes will be sent before the EoR >>falls due -- but the receiving speaker has already flushed their tiny >>posteriors :-( >> >> I am coming to the view that route-refresh during a Graceful Restart >>initial update is a horse of a different colour altogether. >> >> [So the assumption that EoRR and EoR are triggered by the same thing >>was completely wrong, and I apologise for it.] >> >> Chris >> >> _______________________________________________ >> 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 ___________________________________________________________________________= ______________________________________________ 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, 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 authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ 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, 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 authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ 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, 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 authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_5EECE2EC94064BDB8AEBADD1B7ABB167ericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Then make it not a bug.
A second BoRR means the first one was aborted. The draft as it stands = already covers this case.

--
Jakob Heitz.


On Jan 30, 2014, at 8:43 AM, "bruno.decraene@orange.com" <bruno.decraene@orange.com> wrote:

= Hi Keyur,

=  

= Comments inlined #Bruno=

=  

From: Keyur Patel (keyupate) [mailto:keyupate@ci= sco.com]
Sent: Thursday, January 30, = 2014 3:48 PM
To: DECRAENE Bruno IMT/OLN Cc: idr@ietf.org
Subject: Re: [Idr] WG LC for= draft-ietf-idr-bgp-enhanced-route-refresh

 

Hi Bruno,

 

Comments Inlined #Keyur.

 

From: <bruno.de= craene@orange.com>
Date: Thu, 30 Jan 2014 10:27= :56 +0000
To: Keyur Patel <keyupate@cisco.com>
Cc: "idr@ietf.org" <id= r@ietf.org>
Subject: RE: [Idr] WG LC for= draft-ietf-idr-bgp-enhanced-route-refresh

 

= Hi Keyur,

=  

= Thanks for your reply.

= Your proposed new text, using NOT= IFICATION only for syntax errors seems much better to me. Thanks for the clarification.

=  

= Ideally, in addition, I would pre= fer to have a text also covering other types of errors. At least the violation of explicit statement in the draft. E.g. for the following 2= MUST<= /o:p>

=93   Before the speaker starts a route re= fresh that is either initiated

   locally, or in response to a "norm= al route refresh request" from the=

   peer, the speaker MUST send a B= oRR message.  After the speaker

   completes the re-advertisement of the e= ntire Adj-RIB-Out to the peer,

   it MUST send an = EoRR message.=94

=  

= Regarding the first one, IMHO the= re is no harm if the MUST is not enforced. One option may be :s/MUST/SHOULD= ; or a statement in =A7 =93Error handling=94 on how to handle this error (e.= g. log and nothing else).

= Regarding the second one, I=92d l= ike to see a text specifying what should be done when I receive two BoRR. E.g.=

= -a- consider that the second BoRR= should be considered as a EoRR+ BoRR

= -b- ignore/abort the first EoRR p= rocedure (i.e. remark all routes as STALE when the second EoRR is received)<= o:p>

= -c- ignore the second EoRR.

=  

#Keyur: If the sender has sent two Bo= RRs (without an EoRR) then it means it has aborted the first route refresh table announcement and restarted the route refresh table announcem= ent. The second EoRR will be essentially no-op (I.e C case). Implementations can log the no-op behavior.=

= #Bruno : well we don=92t rea= lly know what it means for the sender because it was not supposed to do this in the first place, so it=92s a bug.

Ok for your proposition to ignore the second EoRR. =
Would it be possible to add this sentence/point in the =A7 =93Error handlin=
g?=94 Especially since this seems to contradict the spec  which seems =
more on the side of =93b=94: =93When

 = ;  a BGP speaker receives a BoRR message from a peer, it MUST mark all=

 = ;  the routes with the given <AFI, SAFI> from that peer as stale= .=94

= Thanks,<= /p>

= Regards,=

= Bruno 

 

Regards,

Keyur

 

= (plus obviously log the error in = all cases)

=  

= =93a=94 sounds dangerous to me.

= =93b=94 should a priori ok (accep= t a small error but consider that the speaker remember (and acted as per) its latest message.)

= =93c=94 is the safest path (there= is a error, I don=92t know what it is so I take the safest option)<= /font><= /font>

=  

= Considering the motivation for th= is draft (enhance BGP robustness, but not bring a new feature), I think I would prefer =93c=94 which is the more robust. Especially given = that if the receiver has a doubt, I has a way to clear it by sending a new = Route Refresh message.

= But I guess I would be fine with = =93b=94 if you/the WG have a different opinion.

= (My understanding of the current = draft, is that =93b=94 is expected, but in all cases I would prefer a specific text in  =A7 =93Error handling=94)

=  

= Thanks,

= Cheers,

= Bruno

=  

=  

= From: Keyur Patel (keyupate) [mailto:keyup= ate@cisco.com]
Sent: Wednesday, January 29,= 2014 11:16 PM
To: DECRAENE Bruno IMT/OLN; = Robert Raszuk
Cc: idr@ietf.org
Subject: Re: [Idr] WG LC for= draft-ietf-idr-bgp-enhanced-route-refresh

 =

Hi Bruno,

 

We only generate Notification for invalid length. Ap= ologies for the confusion. Attached is the revised text.

 

Regards,

Keyur

 

<snip>

The error handling specified in this section is appl= icable only when

   a BGP speaker has received the "En= hanced Route Refresh Capability"

   from a peer.

 

   If the length, excluding the fixed-size= message header, of the

   received ROUTE-REFRESH message with Mes= sage Subtype 1 and 2 is not 4,

   then the BGP speaker MUST send a NOTIFI= CATION message with the Error

   Code of "ROUTE-REFRESH Message Err= or" and the subcode of "Invalid

   Message Length".  The Data fi= eld of the NOTIFICATION message MUST

   contain the complete ROUTE-REFRESH mess= age.

 

   When the BGP speaker receives a ROUTE-R= EFRESH message with a "Message

   Subtype" field other than 1 or 2, = it MUST ignore the received ROUTE-

   REFRESH message.  It SHOULD log an= error for further analysis.

 

<snip>

 

From: <bruno.de= craene@orange.com>
Date: Wed, 29 Jan 2014 09:51= :00 +0000
To: Robert Raszuk <robert@raszuk.net>, Keyur Patel <<= a href=3D"mailto:keyupate@cisco.com">keyupate@cisco.com>
Cc: "idr@ietf.org" <id= r@ietf.org>
Subject: RE: [Idr] WG LC for= draft-ietf-idr-bgp-enhanced-route-refresh

 

= Hi all,

=  

=  

 

Hi Jimmy and all,

 

I think Enke and Keyur's proposed text with help from Jakob makes t= he behavior simplified and deterministic to hold on BoRR till first EoR is seen.

 

IMHO it should be also spelled out what is the expected sequence er= ror handling here =

=  

= [Bruno] +1.  And taking = into account possible interaction with draft-ietf-idr-bgp-gr-notification

=  

= BTW:

= =93When the BGP speaker detects a= n error while processing a ROUTE-REFRESH message with a non-zero "Mess= age Subtype" field, it MUST send a NOTIFICATION message with Error Code &= quot;ROUTE-REFRESH Message Error".=94

=  

= Seems a priori not inline with th= e recommendation from draft-ietf-grow-ops-reqs-for-bgp-error-handling (which is to limit the consequences of error handling). Are we sure that n= o error condition could be handled in a more friendly way? (e.g. if BoRR is= not sent following a =93normal route refresh request=94 or if 2 BoRR are s= ent consecutively=85)

=  

= Thanks,

= Regards,

= Bruno

=  

=  

... I think not following "M= UST NOT" shall implicitly result in entire session drop and complete r= estart ? Any error code ?

 

Best,
R.

 

 

On Wed, Jan 29, 2014 at = 9:22 AM, Dongjie (Jimmy) <jie.dong@huawei.com> wrote:

Hi Robert, =

 

Agree that in these cases the RRQ cannot be ignored, so postpone may be a better choice.

 

While IMO stop the initial update and start over may delay the initial convergence, and as you said  it als= o relates to update group processing. What do you think about the new text = provided by Keyur? =

 

Best regards,

Jie

 

From:rraszuk@gmail.com= [mailto:rraszuk@gma= il.com] On Behalf Of Robert Raszuk Sent: Sunday, January 26, 20= 14 11:03 PM
To: Dongjie (Jimmy)
Cc: Keyur Patel (keyupate); = Jakob Heitz; idr@ietf.org


Subject: Re: [Idr] WG LC for= draft-ietf-idr-bgp-enhanced-route-refresh

 

Hi Jie,

 

I think it actually very easy to say that initial update can not ever guarantee that RRQ received during its sending may mee= t the peer's need.

 

Example 1:

 

SAFI 128 - During receiving initial update from RR to PE new VRF got added with new RT import. Unfortunately those updates= received within initial update were already dropped as not interesting by = the PE. RR must resend full table after completed initial update. (Of cours= e this is the case where there is no RTC and that's why RTC helps a lot here by incremental nature). 

 

Example 2: 

 

SAFI 1 - Operator has modified inbound policy on EBGP peer during processing of incoming updates and those originally were = dropped. No soft reconfig in set. =

 

Conclusion:

 

RRQ can not ever be ignored. Sure they can be delayed or batched (case of multiple peers within the same update/peer group) send= ing near RRQs (cluster of PEs got provisioned from central management stati= on). But as Keyur already mentioned those are rather standard local impleme= ntation optimizations. 

 

Question:

 

Does it maybe make sense to stop initial update when receiving RRQ from a peer and start over ? Of course if peer is part = of large update group it would have to be removed dynamically from it so ot= her members are not delayed. In any case I think this does not impact the s= pec but the implementation.

 

Cheers,
R.

 

 

 

On Sun, Jan 26, 2014 at= 7:13 PM, Dongjie (Jimmy) <jie.dong@huawei.com> wrote:

Hi Keyur, Jakob,

Agree that "postpone" may be better. The point is we could avoid = the complicated cases/considerations of performing route refresh during ini= tial update:)

For "ignore", I was thinking of scenarios in which the route refr= esh requirement may already be met by the initial update, while I'd admit i= t is hard to say...



Best regards,
Jie

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

From: Keyur Patel (keyu= pate) [mailto:keyup= ate@cisco.com]
Sent: Sunday, January 26, 2014 8:30 PM
To: Jakob Heitz; Dongjie (Jimmy)
Cc: idr@ietf.org
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Jie,

I agree with Jakob. You could make it *an implementation behavior* to postp= one the route refresh reply.


Regards,
Keyur

On 1/26/14 1:29 AM, "Jakob Heitz" <jakob.heitz@ericsson.com> wrote:<= br>
>You can definitely not ignore it, but you could postpone it.
>
>--
>Jakob Heitz.
>
>> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" <jie.dong@huawei.com>
>>wrote:
>>
>> After reading the analyses in this thread, my personal feeling is<= br> >>maybe we should avoid the interleaving between GR initial update an= d
>>route refresh/enhanced route refresh, since the initial update is j= ust
>>sending the whole Adj-RIB-Out, there is no obvious advantage to sta= rt
>>a route refresh/enhance route refresh during it. So a speaker shoul= d
>>ignore the RRQ received during the initial update. Thoughts?
>>
>> Best regards,
>> Jie
>>
>> -----Original Message-----
>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz
>> Sent: Saturday, January 25, 2014 10:48 PM
>> To: Chris Hall; = idr@ietf.org
>> Subject: Re: [Idr] WG LC for
>> draft-ietf-idr-bgp-enhanced-route-refresh
>>
>> RFCs are written for coders "practiced" in the art"= .
>> If anyone sends an EoRR before the adj-RIB-out is fully populated,=
>>then it's a BUG.
>> This does not need to be said.
>>
>> Personally, I believe a route refresh request should not be honore= d
>>until GR is complete.
>> Also, I don't believe a timer for the receipt of EoRR is necessary= ,
>>because the EoRR is guaranteed.
>> Guaranteed means "unless the session drops first".
>> --
>>
>> Jakob Heitz.
>>
>> ________________________________________
>> From: Chris Hall [chris.hall@highwayman.com]
>> Sent: Saturday, 25 January 2014 11:27 AM
>> To: idr@ietf.org=
>> Cc: Jakob Heitz
>> Subject: RE: [Idr] WG LC for
>> draft-ietf-idr-bgp-enhanced-route-refresh
>>
>> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37):
>> ...
>>> Silence means don't do it.
>>
>> Hmmm.... as a principle I'm more comfortable with "that which= isn't
>>prohibited is permitted"....
>>
>>> You would definitely NOT want BoRR to flush old stales.
>>
>> ....but, given the definite requirement, and given that the curren= t
>>precedent for "marking stale" does flush old stale, then = a few words
>>for the avoidance of doubt ?
>>
>>> Restarting the timer might be a good idea.
>>
>> I dunno... a route which remains stale for "a long time"= is, of
>>course, a candidate for being withdrawn: so having started a timer = the
>>first time things are set stale, I would avoid extending that -- at=
>>least for Graceful Restart, where the whole withdraw thing has been= "on-hold"
>>since the last session failed.  For route-refresh I guess ther= e's more
>>of a presumption that stale routes will be refreshed sooner or late= r,
>>and in the meantime they remain good.  So if the route-refresh= is
>>(repeatedly) restarted for some reason, perhaps it is more reasonab= le
>>to extend the flush deadline -- but avoid doing this indefinitely ?=
>>
>> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I ha= ve
>>built in Quagga prioritise route changes (pending changes and any t= hat
>>occur during the refresh) over refresh updates.  This makes it= more
>>likely that remaining stale routes are still good.  But the ot= her end
>>cannot know that.
>>
>> The paragraph in the draft discussing the "entire Adj-RIB-Out= "
>>defines that to be the entries present "at the start of the ro= ute
>>refresh operation", and observes that these comprise both reac= hable
>>and unreachable routes.  [An "of" after "compri= se" sets teeth on edge,
>>BTW.]  I'm really not sure what this paragraph is trying to te= ll me.
>> The reference to unreachable routes appears to suggest that pendin= g
>>withdraws should be sent as part of the refresh -- so not left to t= he
>>EoRR to implement at the end.  The point at which the EoRR is = sent is
>>defined such that it excludes any Adj-RIB-Out entries added after t= he
>>route-refresh started, but includes any which are changed during th= e
>>process.  It seems reasonable to delay any brand new reachable=
>>prefixes until after all previously announced ones have been refres= hed
>>and the EoRR sent -- if that's the intent here.  Changes which= occur
>>before the refresh gets to a given entry are pretty naturally swept= up
>>by the refresh.  Changes which occur after the refresh has gon= e past,
>>could/should be deferred to after the EoRR ?  Does it make a >>difference if the change is a withdraw ?  (Of course MRAI may = kick in here.  Ah.
>>MRAI and route-refresh, there's a topic !)
>>
>> I think the essence of the rule is that the EoRR should be sent on= ce
>>all prefixes previously advertised to the peer as reachable have be= en
>>refreshed, ie announced or withdrawn (at least) once.  Or, per= haps
>>more strictly, not *before* those prefixes have *all* been announce= d
>>once -- given that the EoRR will promptly bang un-advertised stuff = on the head.
>>Even more strictly perhaps: not send EoRR *before* any withdraws >>implied by it are required or desirable.
>>
>> Depending on the implementation, a given sender may or may not be<= br> >>able to determine the minimum set of updates required before sendin= g EoRR.
>>
>> If the refresh operation takes a long time, there may be good
>>routeing reasons to arrange for some route changes to be sent to th= e peer "early"
>>-- that is to send announcements which do not contribute to the
>>refresh, but which are important enough to warrant delaying the end= of
>>the refresh.  That could be a matter for recommendation(s) in = the standard.
>>
>> NB: given that the timing of the EoRR is tied to the state of the<= br> >>Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. &= nbsp;At
>>the beginning of the initial update, the Restarting and Receiving >>speakers have:
>>
>>  Restarting:  Empty Adj-RIB-In   Empty Adj-RIB-Out<= br> >>
>>  Receiving:   Empty Adj-RIB-Out  Stale Adj-RIB-In >>
>> Now suppose (bonkers or otherwise) the receiving speaker sends an = RRQ
>>part way through the initial update.  The restarting speaker r= esponds
>>with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specifica= tion.
>> The receiving speaker sees the EoRR, and flushes stale.
>>Unfortunately, if the restarting speaker has not yet fully populate= d
>>its Adj-RIB-Out, then many further routes will be sent before the E= oR
>>falls due -- but the receiving speaker has already flushed their ti= ny
>>posteriors :-(
>>
>> I am coming to the view that route-refresh during a Graceful Resta= rt
>>initial update is a horse of a different colour altogether.
>>
>> [So the assumption that EoRR and EoR are triggered by the same thi= ng
>>was completely wrong, and I apologise for it.]
>>
>> Chris
>>
>> _______________________________________________
>> 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
htt= ps://www.ietf.org/mailman/listinfo/idr

 

 = 

______________________________________________=
___________________________________________________________________________=

 
Ce message et ses pieces jointes peuvent conte=
nir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans au=
torisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pi=
eces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce mess=
age a ete altere, deforme ou falsifie. Merci.

 


This message and its attachments may contain c=
onfidential or privileged information that may be protected by law;


they should not be distributed, used or copied=
 without authorisation.


If you have received this email in error, plea=
se notify the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable=
 for messages that have been modified, changed or falsified.


Thank you.


______________________________________________=
___________________________________________________________________________=

 
Ce message et ses pieces jointes peuvent conte=
nir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans au=
torisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pi=
eces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce mess=
age a ete altere, deforme ou falsifie. Merci.

 


This message and its attachments may contain c=
onfidential or privileged information that may be protected by law;


they should not be distributed, used or copied=
 without authorisation.


If you have received this email in error, plea=
se notify the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable=
 for messages that have been modified, changed or falsified.


Thank you.


______________________________________________________________________=
___________________________________________________

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,
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 authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.iet= f.org/mailman/listinfo/idr
--_000_5EECE2EC94064BDB8AEBADD1B7ABB167ericssoncom_-- From keyupate@cisco.com Thu Jan 30 09:38:57 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC481A044A for ; Thu, 30 Jan 2014 09:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8b_tvHVuuUY9 for ; Thu, 30 Jan 2014 09:38:50 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 683BB1A0438 for ; Thu, 30 Jan 2014 09:38:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=102374; q=dns/txt; s=iport; t=1391103526; x=1392313126; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=9+daqmJEWuvBR3ki8HPLZmxNP067hZa67RGIogKMYk0=; b=K9aJVDnU+ykqFLS14D3aNrwfoMOomkIdTZntz1LKkrVLBwAvpuTIMolz qGDMY6bK+W3+C9fVlRv5A/prK32VSll1VY7iInipueT9UWwJem+mBbXlB FZR24Wblkw7CG7DIMK6Zq5lPtd/F68TP6v4spxHufzYkS05n/arQS28RP 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoFAFeN6lKtJXG8/2dsb2JhbABZgkhEOFe9IoEMFnSCJQEBAQQBAQEJDgESQQsMBgEIEQMBAQEWCwEGKAYLFAkIAgQBDQWHcQMRDao0mEINiHgTBIxsgTQLBgElBxMMAQQGAQIEBIQuBJY8gWyMXoVBgy2BaAEGAhci X-IronPort-AV: E=Sophos;i="4.95,751,1384300800"; d="scan'208,217";a="16754858" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-4.cisco.com with ESMTP; 30 Jan 2014 17:38:44 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0UHcicS028104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Jan 2014 17:38:44 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.228]) by xhc-rcd-x04.cisco.com ([::1]) with mapi id 14.03.0123.003; Thu, 30 Jan 2014 11:38:44 -0600 From: "Keyur Patel (keyupate)" To: Jakob Heitz , "bruno.decraene@orange.com" Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPHeIfkeX0Ff7T2kONFJ6OHVSLvw== Date: Thu, 30 Jan 2014 17:38:43 +0000 Message-ID: In-Reply-To: <5EECE2EC-9406-4BDB-8AEB-ADD1B7ABB167@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [128.107.163.31] Content-Type: multipart/alternative; boundary="_000_CF0FCE4A616A7keyupateciscocom_" MIME-Version: 1.0 Cc: "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 17:38:57 -0000 --_000_CF0FCE4A616A7keyupateciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Bruno, Agree with Jakob here. :) The Route Refresh could restart for various reaso= ns (and depending on implementations). In that scenario, it could simply re= send a BoRR again. The receiver side behavior doesn't change in such a case= . Upon a receipt of BoRR mark the routes stale and restart the timer. Having said that implementations could log the receipt of such back-to-back= BoRRs or EoRRs for further analysis. But it doesn't look like a Bug. Regards, Keyur From: Jakob Heitz > Date: Thu, 30 Jan 2014 17:26:12 +0000 To: "bruno.decraene@orange.com" > Cc: Keyur Patel >, "idr@ietf.= org" > Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Then make it not a bug. A second BoRR means the first one was aborted. The draft as it stands alrea= dy covers this case. -- Jakob Heitz. On Jan 30, 2014, at 8:43 AM, "bruno.decraene@orange.com" > wrote: Hi Keyur, Comments inlined #Bruno From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] Sent: Thursday, January 30, 2014 3:48 PM To: DECRAENE Bruno IMT/OLN Cc: idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Bruno, Comments Inlined #Keyur. From:> Date: Thu, 30 Jan 2014 10:27:56 +0000 To: Keyur Patel > Cc: "idr@ietf.org" > Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Keyur, Thanks for your reply. Your proposed new text, using NOTIFICATION only for syntax errors seems muc= h better to me. Thanks for the clarification. Ideally, in addition, I would prefer to have a text also covering other typ= es of errors. At least the violation of explicit statement in the draft. E.= g. for the following 2 MUST =93 Before the speaker starts a route refresh that is either initiated locally, or in response to a "normal route refresh request" from the peer, the speaker MUST send a BoRR message. After the speaker completes the re-advertisement of the entire Adj-RIB-Out to the peer, it MUST send an EoRR message.=94 Regarding the first one, IMHO there is no harm if the MUST is not enforced.= One option may be :s/MUST/SHOULD; or a statement in =A7 =93Error handling= =94 on how to handle this error (e.g. log and nothing else). Regarding the second one, I=92d like to see a text specifying what should b= e done when I receive two BoRR. E.g. -a- consider that the second BoRR should be considered as a EoRR+ BoRR -b- ignore/abort the first EoRR procedure (i.e. remark all routes as STALE = when the second EoRR is received) -c- ignore the second EoRR. #Keyur: If the sender has sent two BoRRs (without an EoRR) then it means it= has aborted the first route refresh table announcement and restarted the r= oute refresh table announcement. The second EoRR will be essentially no-op = (I.e C case). Implementations can log the no-op behavior. #Bruno : well we don=92t really know what it means for the sender because i= t was not supposed to do this in the first place, so it=92s a bug. Ok for your proposition to ignore the second EoRR. Would it be possible to = add this sentence/point in the =A7 =93Error handling?=94 Especially since t= his seems to contradict the spec which seems more on the side of =93b=94: = =93When a BGP speaker receives a BoRR message from a peer, it MUST mark all the routes with the given from that peer as stale.=94 Thanks, Regards, Bruno Regards, Keyur (plus obviously log the error in all cases) =93a=94 sounds dangerous to me. =93b=94 should a priori ok (accept a small error but consider that the spea= ker remember (and acted as per) its latest message.) =93c=94 is the safest path (there is a error, I don=92t know what it is so = I take the safest option) Considering the motivation for this draft (enhance BGP robustness, but not = bring a new feature), I think I would prefer =93c=94 which is the more robu= st. Especially given that if the receiver has a doubt, I has a way to clear= it by sending a new Route Refresh message. But I guess I would be fine with =93b=94 if you/the WG have a different opi= nion. (My understanding of the current draft, is that =93b=94 is expected, but in= all cases I would prefer a specific text in =A7 =93Error handling=94) Thanks, Cheers, Bruno From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] Sent: Wednesday, January 29, 2014 11:16 PM To: DECRAENE Bruno IMT/OLN; Robert Raszuk Cc: idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Bruno, We only generate Notification for invalid length. Apologies for the confusi= on. Attached is the revised text. Regards, Keyur The error handling specified in this section is applicable only when a BGP speaker has received the "Enhanced Route Refresh Capability" from a peer. If the length, excluding the fixed-size message header, of the received ROUTE-REFRESH message with Message Subtype 1 and 2 is not 4, then the BGP speaker MUST send a NOTIFICATION message with the Error Code of "ROUTE-REFRESH Message Error" and the subcode of "Invalid Message Length". The Data field of the NOTIFICATION message MUST contain the complete ROUTE-REFRESH message. When the BGP speaker receives a ROUTE-REFRESH message with a "Message Subtype" field other than 1 or 2, it MUST ignore the received ROUTE- REFRESH message. It SHOULD log an error for further analysis. From: > Date: Wed, 29 Jan 2014 09:51:00 +0000 To: Robert Raszuk >, Keyur Pate= l > Cc: "idr@ietf.org" > Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi all, From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: Wednesday, January 29, 2014 10:15 AM To: Dongjie (Jimmy) Cc: Keyur Patel (keyupate); idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Jimmy and all, I think Enke and Keyur's proposed text with help from Jakob makes the behav= ior simplified and deterministic to hold on BoRR till first EoR is seen. IMHO it should be also spelled out what is the expected sequence error hand= ling here [Bruno] +1. And taking into account possible interaction with draft-ietf-i= dr-bgp-gr-notification BTW: =93When the BGP speaker detects an error while processing a ROUTE-REFRESH m= essage with a non-zero "Message Subtype" field, it MUST send a NOTIFICATION= message with Error Code "ROUTE-REFRESH Message Error".=94 Seems a priori not inline with the recommendation from draft-ietf-grow-ops-= reqs-for-bgp-error-handling (which is to limit the consequences of error ha= ndling). Are we sure that no error condition could be handled in a more fri= endly way? (e.g. if BoRR is not sent following a =93normal route refresh re= quest=94 or if 2 BoRR are sent consecutively=85) Thanks, Regards, Bruno ... I think not following "MUST NOT" shall implicitly result in entire sess= ion drop and complete restart ? Any error code ? Best, R. On Wed, Jan 29, 2014 at 9:22 AM, Dongjie (Jimmy) > wrote: Hi Robert, Agree that in these cases the RRQ cannot be ignored, so postpone may be a b= etter choice. While IMO stop the initial update and start over may delay the initial conv= ergence, and as you said it also relates to update group processing. What = do you think about the new text provided by Keyur? Best regards, Jie From:rraszuk@gmail.com [mailto:rraszuk@gmail.com<= mailto:rraszuk@gmail.com>] On Behalf Of Robert Raszuk Sent: Sunday, January 26, 2014 11:03 PM To: Dongjie (Jimmy) Cc: Keyur Patel (keyupate); Jakob Heitz; idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Jie, I think it actually very easy to say that initial update can not ever guara= ntee that RRQ received during its sending may meet the peer's need. Example 1: SAFI 128 - During receiving initial update from RR to PE new VRF got added = with new RT import. Unfortunately those updates received within initial upd= ate were already dropped as not interesting by the PE. RR must resend full = table after completed initial update. (Of course this is the case where the= re is no RTC and that's why RTC helps a lot here by incremental nature). Example 2: SAFI 1 - Operator has modified inbound policy on EBGP peer during processin= g of incoming updates and those originally were dropped. No soft reconfig i= n set. Conclusion: RRQ can not ever be ignored. Sure they can be delayed or batched (case of m= ultiple peers within the same update/peer group) sending near RRQs (cluster= of PEs got provisioned from central management station). But as Keyur alre= ady mentioned those are rather standard local implementation optimizations. Question: Does it maybe make sense to stop initial update when receiving RRQ from a p= eer and start over ? Of course if peer is part of large update group it wou= ld have to be removed dynamically from it so other members are not delayed.= In any case I think this does not impact the spec but the implementation. Cheers, R. On Sun, Jan 26, 2014 at 7:13 PM, Dongjie (Jimmy) > wrote: Hi Keyur, Jakob, Agree that "postpone" may be better. The point is we could avoid the compli= cated cases/considerations of performing route refresh during initial updat= e:) For "ignore", I was thinking of scenarios in which the route refresh requir= ement may already be met by the initial update, while I'd admit it is hard = to say... Best regards, Jie -----Original Message----- From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] Sent: Sunday, January 26, 2014 8:30 PM To: Jakob Heitz; Dongjie (Jimmy) Cc: idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Jie, I agree with Jakob. You could make it *an implementation behavior* to postp= one the route refresh reply. Regards, Keyur On 1/26/14 1:29 AM, "Jakob Heitz" > wrote: >You can definitely not ignore it, but you could postpone it. > >-- >Jakob Heitz. > >> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" > >>wrote: >> >> After reading the analyses in this thread, my personal feeling is >>maybe we should avoid the interleaving between GR initial update and >>route refresh/enhanced route refresh, since the initial update is just >>sending the whole Adj-RIB-Out, there is no obvious advantage to start >>a route refresh/enhance route refresh during it. So a speaker should >>ignore the RRQ received during the initial update. Thoughts? >> >> Best regards, >> Jie >> >> -----Original Message----- >> From: Idr [mailto:idr-bounces@ietf.org] On = Behalf Of Jakob Heitz >> Sent: Saturday, January 25, 2014 10:48 PM >> To: Chris Hall; idr@ietf.org >> Subject: Re: [Idr] WG LC for >> draft-ietf-idr-bgp-enhanced-route-refresh >> >> RFCs are written for coders "practiced" in the art". >> If anyone sends an EoRR before the adj-RIB-out is fully populated, >>then it's a BUG. >> This does not need to be said. >> >> Personally, I believe a route refresh request should not be honored >>until GR is complete. >> Also, I don't believe a timer for the receipt of EoRR is necessary, >>because the EoRR is guaranteed. >> Guaranteed means "unless the session drops first". >> -- >> >> Jakob Heitz. >> >> ________________________________________ >> From: Chris Hall [chris.hall@highwayman.com] >> Sent: Saturday, 25 January 2014 11:27 AM >> To: idr@ietf.org >> Cc: Jakob Heitz >> Subject: RE: [Idr] WG LC for >> draft-ietf-idr-bgp-enhanced-route-refresh >> >> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): >> ... >>> Silence means don't do it. >> >> Hmmm.... as a principle I'm more comfortable with "that which isn't >>prohibited is permitted".... >> >>> You would definitely NOT want BoRR to flush old stales. >> >> ....but, given the definite requirement, and given that the current >>precedent for "marking stale" does flush old stale, then a few words >>for the avoidance of doubt ? >> >>> Restarting the timer might be a good idea. >> >> I dunno... a route which remains stale for "a long time" is, of >>course, a candidate for being withdrawn: so having started a timer the >>first time things are set stale, I would avoid extending that -- at >>least for Graceful Restart, where the whole withdraw thing has been "on-h= old" >>since the last session failed. For route-refresh I guess there's more >>of a presumption that stale routes will be refreshed sooner or later, >>and in the meantime they remain good. So if the route-refresh is >>(repeatedly) restarted for some reason, perhaps it is more reasonable >>to extend the flush deadline -- but avoid doing this indefinitely ? >> >> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I have >>built in Quagga prioritise route changes (pending changes and any that >>occur during the refresh) over refresh updates. This makes it more >>likely that remaining stale routes are still good. But the other end >>cannot know that. >> >> The paragraph in the draft discussing the "entire Adj-RIB-Out" >>defines that to be the entries present "at the start of the route >>refresh operation", and observes that these comprise both reachable >>and unreachable routes. [An "of" after "comprise" sets teeth on edge, >>BTW.] I'm really not sure what this paragraph is trying to tell me. >> The reference to unreachable routes appears to suggest that pending >>withdraws should be sent as part of the refresh -- so not left to the >>EoRR to implement at the end. The point at which the EoRR is sent is >>defined such that it excludes any Adj-RIB-Out entries added after the >>route-refresh started, but includes any which are changed during the >>process. It seems reasonable to delay any brand new reachable >>prefixes until after all previously announced ones have been refreshed >>and the EoRR sent -- if that's the intent here. Changes which occur >>before the refresh gets to a given entry are pretty naturally swept up >>by the refresh. Changes which occur after the refresh has gone past, >>could/should be deferred to after the EoRR ? Does it make a >>difference if the change is a withdraw ? (Of course MRAI may kick in her= e. Ah. >>MRAI and route-refresh, there's a topic !) >> >> I think the essence of the rule is that the EoRR should be sent once >>all prefixes previously advertised to the peer as reachable have been >>refreshed, ie announced or withdrawn (at least) once. Or, perhaps >>more strictly, not *before* those prefixes have *all* been announced >>once -- given that the EoRR will promptly bang un-advertised stuff on the= head. >>Even more strictly perhaps: not send EoRR *before* any withdraws >>implied by it are required or desirable. >> >> Depending on the implementation, a given sender may or may not be >>able to determine the minimum set of updates required before sending EoRR= . >> >> If the refresh operation takes a long time, there may be good >>routeing reasons to arrange for some route changes to be sent to the peer= "early" >>-- that is to send announcements which do not contribute to the >>refresh, but which are important enough to warrant delaying the end of >>the refresh. That could be a matter for recommendation(s) in the standar= d. >> >> NB: given that the timing of the EoRR is tied to the state of the >>Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. At >>the beginning of the initial update, the Restarting and Receiving >>speakers have: >> >> Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out >> >> Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In >> >> Now suppose (bonkers or otherwise) the receiving speaker sends an RRQ >>part way through the initial update. The restarting speaker responds >>with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specification. >> The receiving speaker sees the EoRR, and flushes stale. >>Unfortunately, if the restarting speaker has not yet fully populated >>its Adj-RIB-Out, then many further routes will be sent before the EoR >>falls due -- but the receiving speaker has already flushed their tiny >>posteriors :-( >> >> I am coming to the view that route-refresh during a Graceful Restart >>initial update is a horse of a different colour altogether. >> >> [So the assumption that EoRR and EoR are triggered by the same thing >>was completely wrong, and I apologise for it.] >> >> Chris >> >> _______________________________________________ >> 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 ___________________________________________________________________________= ______________________________________________ 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, 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 authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ 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, 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 authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ 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, 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 authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_CF0FCE4A616A7keyupateciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Bruno,

Agree with Jakob here. :) The Route Refresh could restart for var= ious reasons (and depending on implementations). In that scenario, it could= simply resend a BoRR again. The receiver side behavior doesn't change in s= uch a case. Upon a receipt of BoRR mark the routes stale and restart the timer.

Having said that implementations could log the receipt of such back-to= -back BoRRs or EoRRs for further analysis. But it doesn't look like a Bug.<= /div>

Regards,
Keyur

From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Thu, 30 Jan 2014 17:26:12 = 3;0000
To: "bruno.decraene@orange.com" <bruno.decraene@orange.com>
Cc: Keyur Patel <keyupate@cisco.com>, "idr@ietf.org" <id= r@ietf.org>
Subject: Re: [Idr] WG LC for draft-= ietf-idr-bgp-enhanced-route-refresh

Then make it not a bug.
A second BoRR means the first one was aborted. The draft as it stands = already covers this case.

--
Jakob Heitz.


On Jan 30, 2014, at 8:43 AM, "bruno.decraene@orange.com" <bruno.decraene@orange.com> wrote:

= Hi Keyur,

=  

= Comments inlined #Bruno

=  

From:= Keyur Patel (keyupate) [mailto:keyupate@ci= sco.com]
Sent: Thursday, January 30, = 2014 3:48 PM
To: DECRAENE Bruno IMT/OLN Cc: idr@ietf.org
Subject: Re: [Idr] WG LC for= draft-ietf-idr-bgp-enhanced-route-refresh

 

Hi Bruno,

 

Comments Inlined #Keyur.

 

From:<bruno.decraene@orange.com>
Date: Thu, 30 Jan 2014 10:27= :56 +0000
To: Keyur Patel <keyupate@cisco.com>
Cc: "idr@ietf.org" <id= r@ietf.org>
Subject: RE: [Idr] WG LC for= draft-ietf-idr-bgp-enhanced-route-refresh

 

= Hi Keyur,

=  =

= Thanks for your reply.

= Your proposed new text, using NOTIFICATION= only for syntax errors seems much better to me. Thanks for the clarification.

=  =

= Ideally, in addition, I would prefer to ha= ve a text also covering other types of errors. At least the violation of explicit statement in the draft. E.g. for the fo= llowing 2 MUST

=93   Before the speaker starts a route refresh= that is either initiated

   locally, or in response to a "normal ro= ute refresh request" from the

   peer, the speaker MUST send a B= oRR message.  After the speaker

   completes the re-advertisement of the entire= Adj-RIB-Out to the peer,

   it MUST send an = EoRR message.=94

=  =

= Regarding the first one, IMHO there is no = harm if the MUST is not enforced. One option may be :s/MUST/SHOULD; or a statement in =A7 =93Error handling=94 on how t= o handle this error (e.g. log and nothing else).

= Regarding the second one, I=92d like to se= e a text specifying what should be done when I receive two BoRR. E.g.

= -a- consider that the second BoRR should b= e considered as a EoRR+ BoRR

= -b- ignore/abort the first EoRR procedure = (i.e. remark all routes as STALE when the second EoRR is received)

= -c- ignore the second EoRR.<= font color=3D"black"><= /p>

=  =

#Keyur: If the sender has sent two BoRRs (without an = EoRR) then it means it has aborted the first route refresh table announcement and restarted the route refresh table ann= ouncement. The second EoRR will be essentially no-op (I.e C case). Im= plementations can log the no-op behavior.

= #Bruno : well we don=92t really kno= w what it means for the sender because it was not supposed to do this in the first place, so it=92s a bug. 

Ok for your proposition to ignore the second EoRR. Would i=
t be possible to add this sentence/point in the =A7 =93Error handling?=94 E=
specially since this seems to contradict the spec  which seems more on=
 the side of =93b=94: =93When=

  = a BGP speaker receives a BoRR message from a peer, it MUST mark all

  = the routes with the given <AFI, SAFI> from that peer as stale.=94

= Thanks,

= Regards,

= Bruno 

 

Regards,

Keyur

 

= (plus obviously log the error in all cases= )

=  =

= =93a=94 sounds dangerous to me.

= =93b=94 should a priori ok (accept a small= error but consider that the speaker remember (and acted as per) its latest message.)

= =93c=94 is the safest path (there is a err= or, I don=92t know what it is so I take the safest option)

=  =

= Considering the motivation for this draft = (enhance BGP robustness, but not bring a new feature), I think I would prefer =93c=94 which is the more robust. Especia= lly given that if the receiver has a doubt, I has a way to clear it by send= ing a new Route Refresh message.

= But I guess I would be fine with =93b=94 i= f you/the WG have a different opinion.<= span style=3D"color:black">

= (My understanding of the current draft, is= that =93b=94 is expected, but in all cases I would prefer a specific text in  =A7 =93Error handling=94)

=  =

= Thanks,

= Cheers,

= Bruno<= span style=3D"color:black">

=  

=  

= From: Keyur Patel (keyupate) [mailto:keyup= ate@cisco.com]
Sent: Wednesday, January 29,= 2014 11:16 PM
To: DECRAENE Bruno IMT/OLN; = Robert Raszuk
Cc: idr@ietf.org
Subject: Re: [Idr] WG LC for= draft-ietf-idr-bgp-enhanced-route-refresh

 =

Hi Bruno,

 

We only generate Notification for invalid length. Apologies for the = confusion. Attached is the revised text.

 

Regards,

Keyur

 

<snip>

The error handling specified in this section is applicable only when= =

   a BGP speaker has received the "Enhanced Route Ref= resh Capability"

   from a peer.

 

   If the length, excluding the fixed-size message header,= of the

   received ROUTE-REFRESH message with Message Subtype 1 a= nd 2 is not 4,

   then the BGP speaker MUST send a NOTIFICATION message w= ith the Error

   Code of "ROUTE-REFRESH Message Error" and the= subcode of "Invalid

   Message Length".  The Data field of the NOTIF= ICATION message MUST

   contain the complete ROUTE-REFRESH message.

 

   When the BGP speaker receives a ROUTE-REFRESH message w= ith a "Message

   Subtype" field other than 1 or 2, it MUST ignore t= he received ROUTE-

   REFRESH message.  It SHOULD log an error for furth= er analysis.

 

<snip>

 

From: = <bruno.decraene@orange.com<= /a>>
Date: Wed, 29 Jan 2014 09:51= :00 +0000
To: Robert Raszuk <robert@raszuk.net>, Keyur Patel <<= a href=3D"mailto:keyupate@cisco.com">keyupate@cisco.com>
Cc: "idr@ietf.org" <id= r@ietf.org>
Subject: RE: [Idr] WG LC for= draft-ietf-idr-bgp-enhanced-route-refresh

 

= Hi all,

=  

=  

 

=

=  

= [Bruno] +1.  And taking into acco= unt possible interaction with draft-ietf-idr-bgp-gr-notification

=  =

= BTW:

= =93When the BGP speaker detects an error w= hile processing a ROUTE-REFRESH message with a non-zero "Message Subtype" field, it MUST send a NOTIFICATION me= ssage with Error Code "ROUTE-REFRESH Message Error".=94

=  =

= Seems a priori not inline with the recomme= ndation from draft-ietf-grow-ops-reqs-for-bgp-error-handling (which is to limit the consequences of error handling). Are we sure that n= o error condition could be handled in a more friendly way? (e.g. if BoRR is= not sent following a =93normal route refresh request=94 or if 2 BoRR are s= ent consecutively=85)

=  =

= Thanks,

= Regards,

= Bruno<= span style=3D"color:black">

=  =

=  =

... I think not following "MUST N= OT" shall implicitly result in entire session drop and complete restar= t ? Any error code ?

 

On Wed, Jan 29, 2014 at = 9:22 AM, Dongjie (Jimmy) <jie.dong@huawei.com> wrote:

Hi Robert, =

 

Agree that in these cases the RRQ cannot be ignored, so postpone may be a better choice.

 

While IMO stop the initial update and start over may delay the initial convergence, and as you said &= nbsp;it also relates to update group processing. What do you think about th= e new text provided by Keyur? =

 

Best regards,

Jie

 

From:rraszuk@gmail.com [mailto:rraszuk@gma= il.com] On Behalf Of Robert Raszuk Sent: Sunday, January 26, 20= 14 11:03 PM
To: Dongjie (Jimmy)
Cc: Keyur Patel (keyupate); = Jakob Heitz; idr@ietf.org


Subject: Re: [Idr] WG LC for= draft-ietf-idr-bgp-enhanced-route-refresh

 

Hi Jie,

 

I think it actually very easy to say that initial update can not ever guarantee that RRQ received during its sending= may meet the peer's need.

 

Example 1:

 

SAFI 128 - During receiving initial update from RR to PE new VRF got added with new RT import. Unfortunately those up= dates received within initial update were already dropped as not interestin= g by the PE. RR must resend full table after completed initial update. (Of = course this is the case where there is no RTC and that's why RTC helps a lot here by incremental nature). = ;

 

Example 2: 

 

SAFI 1 - Operator has modified inbound policy on EBGP peer during processing of incoming updates and those originally we= re dropped. No soft reconfig in set. 

 

Conclusion:

 

RRQ can not ever be ignored. Sure they can be delayed or batched (case of multiple peers within the same update/peer = group) sending near RRQs (cluster of PEs got provisioned from central manag= ement station). But as Keyur already mentioned those are rather standard lo= cal implementation optimizations. =

 

Question:

 

Does it maybe make sense to stop initial update when receiving RRQ from a peer and start over ? Of course if peer is part = of large update group it would have to be removed dynamically from it so ot= her members are not delayed. In any case I think this does not impact the s= pec but the implementation.

 

Cheers,
R.

 

 

 

On Sun, Jan 26, 2014 at= 7:13 PM, Dongjie (Jimmy) <jie.dong@huawei.com> wrote:

Hi Keyur, Jakob,

Agree that "postpone" may be better. The point is we could avoid = the complicated cases/considerations of performing route refresh during ini= tial update:)

For "ignore", I was thinking of scenarios in which the route refr= esh requirement may already be met by the initial update, while I'd admit i= t is hard to say...



Best regards,
Jie

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

From: Keyur Patel (keyu= pate) [mailto:keyup= ate@cisco.com]
Sent: Sunday, January 26, 2014 8:30 PM
To: Jakob Heitz; Dongjie (Jimmy)
Cc: idr@ietf.org
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Jie,

I agree with Jakob. You could make it *an implementation behavior* to postp= one the route refresh reply.


Regards,
Keyur

On 1/26/14 1:29 AM, "Jakob Heitz" <jakob.heitz@ericsson.com> wrote:<= br>
>You can definitely not ignore it, but you could postpone it.
>
>--
>Jakob Heitz.
>
>> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" <jie.dong@huawei.com>
>>wrote:
>>
>> After reading the analyses in this thread, my personal feeling is<= br> >>maybe we should avoid the interleaving between GR initial update an= d
>>route refresh/enhanced route refresh, since the initial update is j= ust
>>sending the whole Adj-RIB-Out, there is no obvious advantage to sta= rt
>>a route refresh/enhance route refresh during it. So a speaker shoul= d
>>ignore the RRQ received during the initial update. Thoughts?
>>
>> Best regards,
>> Jie
>>
>> -----Original Message-----
>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz
>> Sent: Saturday, January 25, 2014 10:48 PM
>> To: Chris Hall; = idr@ietf.org
>> Subject: Re: [Idr] WG LC for
>> draft-ietf-idr-bgp-enhanced-route-refresh
>>
>> RFCs are written for coders "practiced" in the art"= .
>> If anyone sends an EoRR before the adj-RIB-out is fully populated,=
>>then it's a BUG.
>> This does not need to be said.
>>
>> Personally, I believe a route refresh request should not be honore= d
>>until GR is complete.
>> Also, I don't believe a timer for the receipt of EoRR is necessary= ,
>>because the EoRR is guaranteed.
>> Guaranteed means "unless the session drops first".
>> --
>>
>> Jakob Heitz.
>>
>> ________________________________________
>> From: Chris Hall [chris.hall@highwayman.com]
>> Sent: Saturday, 25 January 2014 11:27 AM
>> To: idr@ietf.org=
>> Cc: Jakob Heitz
>> Subject: RE: [Idr] WG LC for
>> draft-ietf-idr-bgp-enhanced-route-refresh
>>
>> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37):
>> ...
>>> Silence means don't do it.
>>
>> Hmmm.... as a principle I'm more comfortable with "that which= isn't
>>prohibited is permitted"....
>>
>>> You would definitely NOT want BoRR to flush old stales.
>>
>> ....but, given the definite requirement, and given that the curren= t
>>precedent for "marking stale" does flush old stale, then = a few words
>>for the avoidance of doubt ?
>>
>>> Restarting the timer might be a good idea.
>>
>> I dunno... a route which remains stale for "a long time"= is, of
>>course, a candidate for being withdrawn: so having started a timer = the
>>first time things are set stale, I would avoid extending that -- at=
>>least for Graceful Restart, where the whole withdraw thing has been= "on-hold"
>>since the last session failed.  For route-refresh I guess ther= e's more
>>of a presumption that stale routes will be refreshed sooner or late= r,
>>and in the meantime they remain good.  So if the route-refresh= is
>>(repeatedly) restarted for some reason, perhaps it is more reasonab= le
>>to extend the flush deadline -- but avoid doing this indefinitely ?=
>>
>> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I ha= ve
>>built in Quagga prioritise route changes (pending changes and any t= hat
>>occur during the refresh) over refresh updates.  This makes it= more
>>likely that remaining stale routes are still good.  But the ot= her end
>>cannot know that.
>>
>> The paragraph in the draft discussing the "entire Adj-RIB-Out= "
>>defines that to be the entries present "at the start of the ro= ute
>>refresh operation", and observes that these comprise both reac= hable
>>and unreachable routes.  [An "of" after "compri= se" sets teeth on edge,
>>BTW.]  I'm really not sure what this paragraph is trying to te= ll me.
>> The reference to unreachable routes appears to suggest that pendin= g
>>withdraws should be sent as part of the refresh -- so not left to t= he
>>EoRR to implement at the end.  The point at which the EoRR is = sent is
>>defined such that it excludes any Adj-RIB-Out entries added after t= he
>>route-refresh started, but includes any which are changed during th= e
>>process.  It seems reasonable to delay any brand new reachable=
>>prefixes until after all previously announced ones have been refres= hed
>>and the EoRR sent -- if that's the intent here.  Changes which= occur
>>before the refresh gets to a given entry are pretty naturally swept= up
>>by the refresh.  Changes which occur after the refresh has gon= e past,
>>could/should be deferred to after the EoRR ?  Does it make a >>difference if the change is a withdraw ?  (Of course MRAI may = kick in here.  Ah.
>>MRAI and route-refresh, there's a topic !)
>>
>> I think the essence of the rule is that the EoRR should be sent on= ce
>>all prefixes previously advertised to the peer as reachable have be= en
>>refreshed, ie announced or withdrawn (at least) once.  Or, per= haps
>>more strictly, not *before* those prefixes have *all* been announce= d
>>once -- given that the EoRR will promptly bang un-advertised stuff = on the head.
>>Even more strictly perhaps: not send EoRR *before* any withdraws >>implied by it are required or desirable.
>>
>> Depending on the implementation, a given sender may or may not be<= br> >>able to determine the minimum set of updates required before sendin= g EoRR.
>>
>> If the refresh operation takes a long time, there may be good
>>routeing reasons to arrange for some route changes to be sent to th= e peer "early"
>>-- that is to send announcements which do not contribute to the
>>refresh, but which are important enough to warrant delaying the end= of
>>the refresh.  That could be a matter for recommendation(s) in = the standard.
>>
>> NB: given that the timing of the EoRR is tied to the state of the<= br> >>Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. &= nbsp;At
>>the beginning of the initial update, the Restarting and Receiving >>speakers have:
>>
>>  Restarting:  Empty Adj-RIB-In   Empty Adj-RIB-Out<= br> >>
>>  Receiving:   Empty Adj-RIB-Out  Stale Adj-RIB-In >>
>> Now suppose (bonkers or otherwise) the receiving speaker sends an = RRQ
>>part way through the initial update.  The restarting speaker r= esponds
>>with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specifica= tion.
>> The receiving speaker sees the EoRR, and flushes stale.
>>Unfortunately, if the restarting speaker has not yet fully populate= d
>>its Adj-RIB-Out, then many further routes will be sent before the E= oR
>>falls due -- but the receiving speaker has already flushed their ti= ny
>>posteriors :-(
>>
>> I am coming to the view that route-refresh during a Graceful Resta= rt
>>initial update is a horse of a different colour altogether.
>>
>> [So the assumption that EoRR and EoR are triggered by the same thi= ng
>>was completely wrong, and I apologise for it.]
>>
>> Chris
>>
>> _______________________________________________
>> 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
htt= ps://www.ietf.org/mailman/listinfo/idr

 

 = 

______________________________________________=
___________________________________________________________________________=

 
Ce message et ses pieces jointes peuvent conte=
nir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans au=
torisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pi=
eces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce mess=
age a ete altere, deforme ou falsifie. Merci.

 


This message and its attachments may contain c=
onfidential or privileged information that may be protected by law;


they should not be distributed, used or copied=
 without authorisation.


If you have received this email in error, plea=
se notify the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable=
 for messages that have been modified, changed or falsified.


Thank you.


______________________________________________=
___________________________________________________________________________=

 
Ce message et ses pieces jointes peuvent conte=
nir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans au=
torisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pi=
eces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce mess=
age a ete altere, deforme ou falsifie. Merci.

 


This message and its attachments may contain c=
onfidential or privileged information that may be protected by law;


they should not be distributed, used or copied=
 without authorisation.


If you have received this email in error, plea=
se notify the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable=
 for messages that have been modified, changed or falsified.


Thank you.


______________________________________________________________________=
___________________________________________________

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,
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 authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.iet= f.org/mailman/listinfo/idr
--_000_CF0FCE4A616A7keyupateciscocom_-- From bdickson@verisign.com Thu Jan 30 09:55:43 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0140E1A0417 for ; Thu, 30 Jan 2014 09:55:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qk86IC-S8nOE for ; Thu, 30 Jan 2014 09:55:37 -0800 (PST) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by ietfa.amsl.com (Postfix) with ESMTP id 725391A03E0 for ; Thu, 30 Jan 2014 09:55:31 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKUuqSELjamsqZCU5BFEBjjK/r6VlgJbFx@postini.com; Thu, 30 Jan 2014 09:55:33 PST Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id s0UHtRfs030533 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Jan 2014 12:55:27 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Thu, 30 Jan 2014 12:55:26 -0500 From: "Dickson, Brian" To: Jakob Heitz , "bruno.decraene@orange.com" Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPF5KdKHMolEg8TF26AxOKep0T6JqRMOhAgAGfMAD//7gu+4AAX1gA//+1BTCAAHhgAP//sQGgAA5+ToAABygAoAAmsOcAAAoIr7AAJlf4AP//r6/0gAEnPAD//8BcWoAA2iqAgAAMEwCAAB6LgIAD81WAgAAOsoCAAAoOAIAA0CeAgADMfwCAAEiuAIAAIASA//+4WTOAAAgogA== Date: Thu, 30 Jan 2014 17:55:25 +0000 Message-ID: In-Reply-To: <5EECE2EC-9406-4BDB-8AEB-ADD1B7ABB167@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_CF0FFB141009Cbdicksonverisigncom_" MIME-Version: 1.0 Cc: "Keyur Patel \(keyupate\)" , "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 17:55:43 -0000 --_000_CF0FFB141009Cbdicksonverisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I think there may need to be something akin to a state machine diagram, jus= t so everything is crystal clear to all current and future implementers. I don't think it would be too complex, but should handle the cases discusse= d. Just my opinion, feel free to ignore. However, the discussion during LC wou= ld suggest that such a diagram might be helpful. Brian From: Jakob Heitz > Date: Thursday, January 30, 2014 12:26 PM To: "bruno.decraene@orange.com" > Cc: "Keyur Patel (keyupate)" = >, "idr@ietf.org" > Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Then make it not a bug. A second BoRR means the first one was aborted. The draft as it stands alrea= dy covers this case. -- Jakob Heitz. On Jan 30, 2014, at 8:43 AM, "bruno.decraene@orange.com" > wrote: Hi Keyur, Comments inlined #Bruno From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] Sent: Thursday, January 30, 2014 3:48 PM To: DECRAENE Bruno IMT/OLN Cc: idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Bruno, Comments Inlined #Keyur. From: > Date: Thu, 30 Jan 2014 10:27:56 +0000 To: Keyur Patel > Cc: "idr@ietf.org" > Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Keyur, Thanks for your reply. Your proposed new text, using NOTIFICATION only for syntax errors seems muc= h better to me. Thanks for the clarification. Ideally, in addition, I would prefer to have a text also covering other typ= es of errors. At least the violation of explicit statement in the draft. E.= g. for the following 2 MUST =93 Before the speaker starts a route refresh that is either initiated locally, or in response to a "normal route refresh request" from the peer, the speaker MUST send a BoRR message. After the speaker completes the re-advertisement of the entire Adj-RIB-Out to the peer, it MUST send an EoRR message.=94 Regarding the first one, IMHO there is no harm if the MUST is not enforced.= One option may be :s/MUST/SHOULD; or a statement in =A7 =93Error handling= =94 on how to handle this error (e.g. log and nothing else). Regarding the second one, I=92d like to see a text specifying what should b= e done when I receive two BoRR. E.g. -a- consider that the second BoRR should be considered as a EoRR+ BoRR -b- ignore/abort the first EoRR procedure (i.e. remark all routes as STALE = when the second EoRR is received) -c- ignore the second EoRR. #Keyur: If the sender has sent two BoRRs (without an EoRR) then it means it= has aborted the first route refresh table announcement and restarted the r= oute refresh table announcement. The second EoRR will be essentially no-op = (I.e C case). Implementations can log the no-op behavior. #Bruno : well we don=92t really know what it means for the sender because i= t was not supposed to do this in the first place, so it=92s a bug. Ok for your proposition to ignore the second EoRR. Would it be possible to = add this sentence/point in the =A7 =93Error handling?=94 Especially since t= his seems to contradict the spec which seems more on the side of =93b=94: = =93When a BGP speaker receives a BoRR message from a peer, it MUST mark all the routes with the given from that peer as stale.=94 Thanks, Regards, Bruno Regards, Keyur (plus obviously log the error in all cases) =93a=94 sounds dangerous to me. =93b=94 should a priori ok (accept a small error but consider that the spea= ker remember (and acted as per) its latest message.) =93c=94 is the safest path (there is a error, I don=92t know what it is so = I take the safest option) Considering the motivation for this draft (enhance BGP robustness, but not = bring a new feature), I think I would prefer =93c=94 which is the more robu= st. Especially given that if the receiver has a doubt, I has a way to clear= it by sending a new Route Refresh message. But I guess I would be fine with =93b=94 if you/the WG have a different opi= nion. (My understanding of the current draft, is that =93b=94 is expected, but in= all cases I would prefer a specific text in =A7 =93Error handling=94) Thanks, Cheers, Bruno From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] Sent: Wednesday, January 29, 2014 11:16 PM To: DECRAENE Bruno IMT/OLN; Robert Raszuk Cc: idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Bruno, We only generate Notification for invalid length. Apologies for the confusi= on. Attached is the revised text. Regards, Keyur The error handling specified in this section is applicable only when a BGP speaker has received the "Enhanced Route Refresh Capability" from a peer. If the length, excluding the fixed-size message header, of the received ROUTE-REFRESH message with Message Subtype 1 and 2 is not 4, then the BGP speaker MUST send a NOTIFICATION message with the Error Code of "ROUTE-REFRESH Message Error" and the subcode of "Invalid Message Length". The Data field of the NOTIFICATION message MUST contain the complete ROUTE-REFRESH message. When the BGP speaker receives a ROUTE-REFRESH message with a "Message Subtype" field other than 1 or 2, it MUST ignore the received ROUTE- REFRESH message. It SHOULD log an error for further analysis. From: > Date: Wed, 29 Jan 2014 09:51:00 +0000 To: Robert Raszuk >, Keyur Pate= l > Cc: "idr@ietf.org" > Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi all, From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: Wednesday, January 29, 2014 10:15 AM To: Dongjie (Jimmy) Cc: Keyur Patel (keyupate); idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Jimmy and all, I think Enke and Keyur's proposed text with help from Jakob makes the behav= ior simplified and deterministic to hold on BoRR till first EoR is seen. IMHO it should be also spelled out what is the expected sequence error hand= ling here [Bruno] +1. And taking into account possible interaction with draft-ietf-i= dr-bgp-gr-notification BTW: =93When the BGP speaker detects an error while processing a ROUTE-REFRESH m= essage with a non-zero "Message Subtype" field, it MUST send a NOTIFICATION= message with Error Code "ROUTE-REFRESH Message Error".=94 Seems a priori not inline with the recommendation from draft-ietf-grow-ops-= reqs-for-bgp-error-handling (which is to limit the consequences of error ha= ndling). Are we sure that no error condition could be handled in a more fri= endly way? (e.g. if BoRR is not sent following a =93normal route refresh re= quest=94 or if 2 BoRR are sent consecutively=85) Thanks, Regards, Bruno ... I think not following "MUST NOT" shall implicitly result in entire sess= ion drop and complete restart ? Any error code ? Best, R. On Wed, Jan 29, 2014 at 9:22 AM, Dongjie (Jimmy) > wrote: Hi Robert, Agree that in these cases the RRQ cannot be ignored, so postpone may be a b= etter choice. While IMO stop the initial update and start over may delay the initial conv= ergence, and as you said it also relates to update group processing. What = do you think about the new text provided by Keyur? Best regards, Jie From:rraszuk@gmail.com [mailto:rraszuk@gmail.com<= mailto:rraszuk@gmail.com>] On Behalf Of Robert Raszuk Sent: Sunday, January 26, 2014 11:03 PM To: Dongjie (Jimmy) Cc: Keyur Patel (keyupate); Jakob Heitz; idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Jie, I think it actually very easy to say that initial update can not ever guara= ntee that RRQ received during its sending may meet the peer's need. Example 1: SAFI 128 - During receiving initial update from RR to PE new VRF got added = with new RT import. Unfortunately those updates received within initial upd= ate were already dropped as not interesting by the PE. RR must resend full = table after completed initial update. (Of course this is the case where the= re is no RTC and that's why RTC helps a lot here by incremental nature). Example 2: SAFI 1 - Operator has modified inbound policy on EBGP peer during processin= g of incoming updates and those originally were dropped. No soft reconfig i= n set. Conclusion: RRQ can not ever be ignored. Sure they can be delayed or batched (case of m= ultiple peers within the same update/peer group) sending near RRQs (cluster= of PEs got provisioned from central management station). But as Keyur alre= ady mentioned those are rather standard local implementation optimizations. Question: Does it maybe make sense to stop initial update when receiving RRQ from a p= eer and start over ? Of course if peer is part of large update group it wou= ld have to be removed dynamically from it so other members are not delayed.= In any case I think this does not impact the spec but the implementation. Cheers, R. On Sun, Jan 26, 2014 at 7:13 PM, Dongjie (Jimmy) > wrote: Hi Keyur, Jakob, Agree that "postpone" may be better. The point is we could avoid the compli= cated cases/considerations of performing route refresh during initial updat= e:) For "ignore", I was thinking of scenarios in which the route refresh requir= ement may already be met by the initial update, while I'd admit it is hard = to say... Best regards, Jie -----Original Message----- From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] Sent: Sunday, January 26, 2014 8:30 PM To: Jakob Heitz; Dongjie (Jimmy) Cc: idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Jie, I agree with Jakob. You could make it *an implementation behavior* to postp= one the route refresh reply. Regards, Keyur On 1/26/14 1:29 AM, "Jakob Heitz" > wrote: >You can definitely not ignore it, but you could postpone it. > >-- >Jakob Heitz. > >> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" > >>wrote: >> >> After reading the analyses in this thread, my personal feeling is >>maybe we should avoid the interleaving between GR initial update and >>route refresh/enhanced route refresh, since the initial update is just >>sending the whole Adj-RIB-Out, there is no obvious advantage to start >>a route refresh/enhance route refresh during it. So a speaker should >>ignore the RRQ received during the initial update. Thoughts? >> >> Best regards, >> Jie >> >> -----Original Message----- >> From: Idr [mailto:idr-bounces@ietf.org] On = Behalf Of Jakob Heitz >> Sent: Saturday, January 25, 2014 10:48 PM >> To: Chris Hall; idr@ietf.org >> Subject: Re: [Idr] WG LC for >> draft-ietf-idr-bgp-enhanced-route-refresh >> >> RFCs are written for coders "practiced" in the art". >> If anyone sends an EoRR before the adj-RIB-out is fully populated, >>then it's a BUG. >> This does not need to be said. >> >> Personally, I believe a route refresh request should not be honored >>until GR is complete. >> Also, I don't believe a timer for the receipt of EoRR is necessary, >>because the EoRR is guaranteed. >> Guaranteed means "unless the session drops first". >> -- >> >> Jakob Heitz. >> >> ________________________________________ >> From: Chris Hall [chris.hall@highwayman.com] >> Sent: Saturday, 25 January 2014 11:27 AM >> To: idr@ietf.org >> Cc: Jakob Heitz >> Subject: RE: [Idr] WG LC for >> draft-ietf-idr-bgp-enhanced-route-refresh >> >> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): >> ... >>> Silence means don't do it. >> >> Hmmm.... as a principle I'm more comfortable with "that which isn't >>prohibited is permitted".... >> >>> You would definitely NOT want BoRR to flush old stales. >> >> ....but, given the definite requirement, and given that the current >>precedent for "marking stale" does flush old stale, then a few words >>for the avoidance of doubt ? >> >>> Restarting the timer might be a good idea. >> >> I dunno... a route which remains stale for "a long time" is, of >>course, a candidate for being withdrawn: so having started a timer the >>first time things are set stale, I would avoid extending that -- at >>least for Graceful Restart, where the whole withdraw thing has been "on-h= old" >>since the last session failed. For route-refresh I guess there's more >>of a presumption that stale routes will be refreshed sooner or later, >>and in the meantime they remain good. So if the route-refresh is >>(repeatedly) restarted for some reason, perhaps it is more reasonable >>to extend the flush deadline -- but avoid doing this indefinitely ? >> >> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I have >>built in Quagga prioritise route changes (pending changes and any that >>occur during the refresh) over refresh updates. This makes it more >>likely that remaining stale routes are still good. But the other end >>cannot know that. >> >> The paragraph in the draft discussing the "entire Adj-RIB-Out" >>defines that to be the entries present "at the start of the route >>refresh operation", and observes that these comprise both reachable >>and unreachable routes. [An "of" after "comprise" sets teeth on edge, >>BTW.] I'm really not sure what this paragraph is trying to tell me. >> The reference to unreachable routes appears to suggest that pending >>withdraws should be sent as part of the refresh -- so not left to the >>EoRR to implement at the end. The point at which the EoRR is sent is >>defined such that it excludes any Adj-RIB-Out entries added after the >>route-refresh started, but includes any which are changed during the >>process. It seems reasonable to delay any brand new reachable >>prefixes until after all previously announced ones have been refreshed >>and the EoRR sent -- if that's the intent here. Changes which occur >>before the refresh gets to a given entry are pretty naturally swept up >>by the refresh. Changes which occur after the refresh has gone past, >>could/should be deferred to after the EoRR ? Does it make a >>difference if the change is a withdraw ? (Of course MRAI may kick in her= e. Ah. >>MRAI and route-refresh, there's a topic !) >> >> I think the essence of the rule is that the EoRR should be sent once >>all prefixes previously advertised to the peer as reachable have been >>refreshed, ie announced or withdrawn (at least) once. Or, perhaps >>more strictly, not *before* those prefixes have *all* been announced >>once -- given that the EoRR will promptly bang un-advertised stuff on the= head. >>Even more strictly perhaps: not send EoRR *before* any withdraws >>implied by it are required or desirable. >> >> Depending on the implementation, a given sender may or may not be >>able to determine the minimum set of updates required before sending EoRR= . >> >> If the refresh operation takes a long time, there may be good >>routeing reasons to arrange for some route changes to be sent to the peer= "early" >>-- that is to send announcements which do not contribute to the >>refresh, but which are important enough to warrant delaying the end of >>the refresh. That could be a matter for recommendation(s) in the standar= d. >> >> NB: given that the timing of the EoRR is tied to the state of the >>Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. At >>the beginning of the initial update, the Restarting and Receiving >>speakers have: >> >> Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out >> >> Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In >> >> Now suppose (bonkers or otherwise) the receiving speaker sends an RRQ >>part way through the initial update. The restarting speaker responds >>with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specification. >> The receiving speaker sees the EoRR, and flushes stale. >>Unfortunately, if the restarting speaker has not yet fully populated >>its Adj-RIB-Out, then many further routes will be sent before the EoR >>falls due -- but the receiving speaker has already flushed their tiny >>posteriors :-( >> >> I am coming to the view that route-refresh during a Graceful Restart >>initial update is a horse of a different colour altogether. >> >> [So the assumption that EoRR and EoR are triggered by the same thing >>was completely wrong, and I apologise for it.] >> >> Chris >> >> _______________________________________________ >> 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 ___________________________________________________________________________= ______________________________________________ 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, 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 authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ 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, 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 authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ 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, 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 authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_CF0FFB141009Cbdicksonverisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <3841D20274C5A54295A5AFAA5A28F4B2@verisign.com> Content-Transfer-Encoding: quoted-printable
I think there may need to be something akin to a state machine diagram= , just so everything is crystal clear to all current and future implementer= s.

I don't think it would be too complex, but should handle the cases dis= cussed.

Just my opinion, feel free to ignore. However, the discussion during L= C would suggest that such a diagram might be helpful.

Brian

From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Thursday, January 30, 2014 12= :26 PM
To: "bruno.decraene@orange.com" <bruno.decraene@orange.com>
Cc: "Keyur Patel (keyupate)&qu= ot; <keyupate@cisco.com>, &= quot;idr@ietf.org" <idr@ietf.org>
Subject: Re: [Idr] WG LC for draft-= ietf-idr-bgp-enhanced-route-refresh

Then make it not a bug.
A second BoRR means the first one was aborted. The draft as it stands = already covers this case.

--
Jakob Heitz.


On Jan 30, 2014, at 8:43 AM, "bruno.decraene@orange.com" <bruno.decraene@orange.com> wrote:

= Hi Keyur,

=  

= Comments inlined #Bruno

=  

From:= Keyur Patel (keyupate) [mailto:keyupate@ci= sco.com]
Sent: Thursday, January 30, = 2014 3:48 PM
To: DECRAENE Bruno IMT/OLN Cc: idr@ietf.org
Subject: Re: [Idr] WG LC for= draft-ietf-idr-bgp-enhanced-route-refresh

 

Hi Bruno,

 

Comments Inlined #Keyur.

 

From: = <bruno.decraene@orange.com<= /a>>
Date: Thu, 30 Jan 2014 10:27= :56 +0000
To: Keyur Patel <keyupate@cisco.com>
Cc: "idr@ietf.org" <id= r@ietf.org>
Subject: RE: [Idr] WG LC for= draft-ietf-idr-bgp-enhanced-route-refresh

 

= Hi Keyur,

=  =

= Thanks for your reply.

= Your proposed new text, using NOTIFICATION= only for syntax errors seems much better to me. Thanks for the clarification.

=  =

= Ideally, in addition, I would prefer to ha= ve a text also covering other types of errors. At least the violation of explicit statement in the draft. E.g. for the fo= llowing 2 MUST

=93   Before the speaker starts a route refresh= that is either initiated

   locally, or in response to a "normal ro= ute refresh request" from the

   peer, the speaker MUST send a B= oRR message.  After the speaker

   completes the re-advertisement of the entire= Adj-RIB-Out to the peer,

   it MUST send an = EoRR message.=94

=  =

= Regarding the first one, IMHO there is no = harm if the MUST is not enforced. One option may be :s/MUST/SHOULD; or a statement in =A7 =93Error handling=94 on how t= o handle this error (e.g. log and nothing else).

= Regarding the second one, I=92d like to se= e a text specifying what should be done when I receive two BoRR. E.g.

= -a- consider that the second BoRR should b= e considered as a EoRR+ BoRR

= -b- ignore/abort the first EoRR procedure = (i.e. remark all routes as STALE when the second EoRR is received)

= -c- ignore the second EoRR.<= font color=3D"black"><= /p>

=  =

#Keyur: If the sender has sent two BoRRs (without an = EoRR) then it means it has aborted the first route refresh table announcement and restarted the route refresh table ann= ouncement. The second EoRR will be essentially no-op (I.e C case). Im= plementations can log the no-op behavior.

= #Bruno : well we don=92t really kno= w what it means for the sender because it was not supposed to do this in the first place, so it=92s a bug. 

Ok for your proposition to ignore the second EoRR. Would i=
t be possible to add this sentence/point in the =A7 =93Error handling?=94 E=
specially since this seems to contradict the spec  which seems more on=
 the side of =93b=94: =93When=

  = a BGP speaker receives a BoRR message from a peer, it MUST mark all

  = the routes with the given <AFI, SAFI> from that peer as stale.=94

= Thanks,

= Regards,

= Bruno 

 

Regards,

Keyur

 

= (plus obviously log the error in all cases= )

=  =

= =93a=94 sounds dangerous to me.

= =93b=94 should a priori ok (accept a small= error but consider that the speaker remember (and acted as per) its latest message.)

= =93c=94 is the safest path (there is a err= or, I don=92t know what it is so I take the safest option)

=  =

= Considering the motivation for this draft = (enhance BGP robustness, but not bring a new feature), I think I would prefer =93c=94 which is the more robust. Especia= lly given that if the receiver has a doubt, I has a way to clear it by send= ing a new Route Refresh message.

= But I guess I would be fine with =93b=94 i= f you/the WG have a different opinion.<= span style=3D"color:black">

= (My understanding of the current draft, is= that =93b=94 is expected, but in all cases I would prefer a specific text in  =A7 =93Error handling=94)

=  =

= Thanks,

= Cheers,

= Bruno<= span style=3D"color:black">

=  

=  

= From: Keyur Patel (keyupate) [mailto:keyup= ate@cisco.com]
Sent: Wednesday, January 29,= 2014 11:16 PM
To: DECRAENE Bruno IMT/OLN; = Robert Raszuk
Cc: idr@ietf.org
Subject: Re: [Idr] WG LC for= draft-ietf-idr-bgp-enhanced-route-refresh

 =

Hi Bruno,

 

We only generate Notification for invalid length. Apologies for the = confusion. Attached is the revised text.

 

Regards,

Keyur

 

<snip>

The error handling specified in this section is applicable only when= =

   a BGP speaker has received the "Enhanced Route Ref= resh Capability"

   from a peer.

 

   If the length, excluding the fixed-size message header,= of the

   received ROUTE-REFRESH message with Message Subtype 1 a= nd 2 is not 4,

   then the BGP speaker MUST send a NOTIFICATION message w= ith the Error

   Code of "ROUTE-REFRESH Message Error" and the= subcode of "Invalid

   Message Length".  The Data field of the NOTIF= ICATION message MUST

   contain the complete ROUTE-REFRESH message.

 

   When the BGP speaker receives a ROUTE-REFRESH message w= ith a "Message

   Subtype" field other than 1 or 2, it MUST ignore t= he received ROUTE-

   REFRESH message.  It SHOULD log an error for furth= er analysis.

 

<snip>

 

From: = <bruno.decraene@orange.com<= /a>>
Date: Wed, 29 Jan 2014 09:51= :00 +0000
To: Robert Raszuk <robert@raszuk.net>, Keyur Patel <<= a href=3D"mailto:keyupate@cisco.com">keyupate@cisco.com>
Cc: "idr@ietf.org" <id= r@ietf.org>
Subject: RE: [Idr] WG LC for= draft-ietf-idr-bgp-enhanced-route-refresh

 

= Hi all,

=  

=  

 

=

=  

= [Bruno] +1.  And taking into acco= unt possible interaction with draft-ietf-idr-bgp-gr-notification

=  =

= BTW:

= =93When the BGP speaker detects an error w= hile processing a ROUTE-REFRESH message with a non-zero "Message Subtype" field, it MUST send a NOTIFICATION me= ssage with Error Code "ROUTE-REFRESH Message Error".=94

=  =

= Seems a priori not inline with the recomme= ndation from draft-ietf-grow-ops-reqs-for-bgp-error-handling (which is to limit the consequences of error handling). Are we sure that n= o error condition could be handled in a more friendly way? (e.g. if BoRR is= not sent following a =93normal route refresh request=94 or if 2 BoRR are s= ent consecutively=85)

=  =

= Thanks,

= Regards,

= Bruno<= span style=3D"color:black">

=  =

=  =

... I think not following "MUST N= OT" shall implicitly result in entire session drop and complete restar= t ? Any error code ?

 

On Wed, Jan 29, 2014 at = 9:22 AM, Dongjie (Jimmy) <jie.dong@huawei.com> wrote:

Hi Robert, =

 

Agree that in these cases the RRQ cannot be ignored, so postpone may be a better choice.

 

While IMO stop the initial update and start over may delay the initial convergence, and as you said &= nbsp;it also relates to update group processing. What do you think about th= e new text provided by Keyur? =

 

Best regards,

Jie

 

From:rraszuk@gmail.com [mailto:rraszuk@gma= il.com] On Behalf Of Robert Raszuk Sent: Sunday, January 26, 20= 14 11:03 PM
To: Dongjie (Jimmy)
Cc: Keyur Patel (keyupate); = Jakob Heitz; idr@ietf.org


Subject: Re: [Idr] WG LC for= draft-ietf-idr-bgp-enhanced-route-refresh

 

Hi Jie,

 

I think it actually very easy to say that initial update can not ever guarantee that RRQ received during its sending= may meet the peer's need.

 

Example 1:

 

SAFI 128 - During receiving initial update from RR to PE new VRF got added with new RT import. Unfortunately those up= dates received within initial update were already dropped as not interestin= g by the PE. RR must resend full table after completed initial update. (Of = course this is the case where there is no RTC and that's why RTC helps a lot here by incremental nature). = ;

 

Example 2: 

 

SAFI 1 - Operator has modified inbound policy on EBGP peer during processing of incoming updates and those originally we= re dropped. No soft reconfig in set. 

 

Conclusion:

 

RRQ can not ever be ignored. Sure they can be delayed or batched (case of multiple peers within the same update/peer = group) sending near RRQs (cluster of PEs got provisioned from central manag= ement station). But as Keyur already mentioned those are rather standard lo= cal implementation optimizations. =

 

Question:

 

Does it maybe make sense to stop initial update when receiving RRQ from a peer and start over ? Of course if peer is part = of large update group it would have to be removed dynamically from it so ot= her members are not delayed. In any case I think this does not impact the s= pec but the implementation.

 

Cheers,
R.

 

 

 

On Sun, Jan 26, 2014 at= 7:13 PM, Dongjie (Jimmy) <jie.dong@huawei.com> wrote:

Hi Keyur, Jakob,

Agree that "postpone" may be better. The point is we could avoid = the complicated cases/considerations of performing route refresh during ini= tial update:)

For "ignore", I was thinking of scenarios in which the route refr= esh requirement may already be met by the initial update, while I'd admit i= t is hard to say...



Best regards,
Jie

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

From: Keyur Patel (keyu= pate) [mailto:keyup= ate@cisco.com]
Sent: Sunday, January 26, 2014 8:30 PM
To: Jakob Heitz; Dongjie (Jimmy)
Cc: idr@ietf.org
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Jie,

I agree with Jakob. You could make it *an implementation behavior* to postp= one the route refresh reply.


Regards,
Keyur

On 1/26/14 1:29 AM, "Jakob Heitz" <jakob.heitz@ericsson.com> wrote:<= br>
>You can definitely not ignore it, but you could postpone it.
>
>--
>Jakob Heitz.
>
>> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" <jie.dong@huawei.com>
>>wrote:
>>
>> After reading the analyses in this thread, my personal feeling is<= br> >>maybe we should avoid the interleaving between GR initial update an= d
>>route refresh/enhanced route refresh, since the initial update is j= ust
>>sending the whole Adj-RIB-Out, there is no obvious advantage to sta= rt
>>a route refresh/enhance route refresh during it. So a speaker shoul= d
>>ignore the RRQ received during the initial update. Thoughts?
>>
>> Best regards,
>> Jie
>>
>> -----Original Message-----
>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz
>> Sent: Saturday, January 25, 2014 10:48 PM
>> To: Chris Hall; = idr@ietf.org
>> Subject: Re: [Idr] WG LC for
>> draft-ietf-idr-bgp-enhanced-route-refresh
>>
>> RFCs are written for coders "practiced" in the art"= .
>> If anyone sends an EoRR before the adj-RIB-out is fully populated,=
>>then it's a BUG.
>> This does not need to be said.
>>
>> Personally, I believe a route refresh request should not be honore= d
>>until GR is complete.
>> Also, I don't believe a timer for the receipt of EoRR is necessary= ,
>>because the EoRR is guaranteed.
>> Guaranteed means "unless the session drops first".
>> --
>>
>> Jakob Heitz.
>>
>> ________________________________________
>> From: Chris Hall [chris.hall@highwayman.com]
>> Sent: Saturday, 25 January 2014 11:27 AM
>> To: idr@ietf.org=
>> Cc: Jakob Heitz
>> Subject: RE: [Idr] WG LC for
>> draft-ietf-idr-bgp-enhanced-route-refresh
>>
>> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37):
>> ...
>>> Silence means don't do it.
>>
>> Hmmm.... as a principle I'm more comfortable with "that which= isn't
>>prohibited is permitted"....
>>
>>> You would definitely NOT want BoRR to flush old stales.
>>
>> ....but, given the definite requirement, and given that the curren= t
>>precedent for "marking stale" does flush old stale, then = a few words
>>for the avoidance of doubt ?
>>
>>> Restarting the timer might be a good idea.
>>
>> I dunno... a route which remains stale for "a long time"= is, of
>>course, a candidate for being withdrawn: so having started a timer = the
>>first time things are set stale, I would avoid extending that -- at=
>>least for Graceful Restart, where the whole withdraw thing has been= "on-hold"
>>since the last session failed.  For route-refresh I guess ther= e's more
>>of a presumption that stale routes will be refreshed sooner or late= r,
>>and in the meantime they remain good.  So if the route-refresh= is
>>(repeatedly) restarted for some reason, perhaps it is more reasonab= le
>>to extend the flush deadline -- but avoid doing this indefinitely ?=
>>
>> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I ha= ve
>>built in Quagga prioritise route changes (pending changes and any t= hat
>>occur during the refresh) over refresh updates.  This makes it= more
>>likely that remaining stale routes are still good.  But the ot= her end
>>cannot know that.
>>
>> The paragraph in the draft discussing the "entire Adj-RIB-Out= "
>>defines that to be the entries present "at the start of the ro= ute
>>refresh operation", and observes that these comprise both reac= hable
>>and unreachable routes.  [An "of" after "compri= se" sets teeth on edge,
>>BTW.]  I'm really not sure what this paragraph is trying to te= ll me.
>> The reference to unreachable routes appears to suggest that pendin= g
>>withdraws should be sent as part of the refresh -- so not left to t= he
>>EoRR to implement at the end.  The point at which the EoRR is = sent is
>>defined such that it excludes any Adj-RIB-Out entries added after t= he
>>route-refresh started, but includes any which are changed during th= e
>>process.  It seems reasonable to delay any brand new reachable=
>>prefixes until after all previously announced ones have been refres= hed
>>and the EoRR sent -- if that's the intent here.  Changes which= occur
>>before the refresh gets to a given entry are pretty naturally swept= up
>>by the refresh.  Changes which occur after the refresh has gon= e past,
>>could/should be deferred to after the EoRR ?  Does it make a >>difference if the change is a withdraw ?  (Of course MRAI may = kick in here.  Ah.
>>MRAI and route-refresh, there's a topic !)
>>
>> I think the essence of the rule is that the EoRR should be sent on= ce
>>all prefixes previously advertised to the peer as reachable have be= en
>>refreshed, ie announced or withdrawn (at least) once.  Or, per= haps
>>more strictly, not *before* those prefixes have *all* been announce= d
>>once -- given that the EoRR will promptly bang un-advertised stuff = on the head.
>>Even more strictly perhaps: not send EoRR *before* any withdraws >>implied by it are required or desirable.
>>
>> Depending on the implementation, a given sender may or may not be<= br> >>able to determine the minimum set of updates required before sendin= g EoRR.
>>
>> If the refresh operation takes a long time, there may be good
>>routeing reasons to arrange for some route changes to be sent to th= e peer "early"
>>-- that is to send announcements which do not contribute to the
>>refresh, but which are important enough to warrant delaying the end= of
>>the refresh.  That could be a matter for recommendation(s) in = the standard.
>>
>> NB: given that the timing of the EoRR is tied to the state of the<= br> >>Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. &= nbsp;At
>>the beginning of the initial update, the Restarting and Receiving >>speakers have:
>>
>>  Restarting:  Empty Adj-RIB-In   Empty Adj-RIB-Out<= br> >>
>>  Receiving:   Empty Adj-RIB-Out  Stale Adj-RIB-In >>
>> Now suppose (bonkers or otherwise) the receiving speaker sends an = RRQ
>>part way through the initial update.  The restarting speaker r= esponds
>>with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specifica= tion.
>> The receiving speaker sees the EoRR, and flushes stale.
>>Unfortunately, if the restarting speaker has not yet fully populate= d
>>its Adj-RIB-Out, then many further routes will be sent before the E= oR
>>falls due -- but the receiving speaker has already flushed their ti= ny
>>posteriors :-(
>>
>> I am coming to the view that route-refresh during a Graceful Resta= rt
>>initial update is a horse of a different colour altogether.
>>
>> [So the assumption that EoRR and EoR are triggered by the same thi= ng
>>was completely wrong, and I apologise for it.]
>>
>> Chris
>>
>> _______________________________________________
>> 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
htt= ps://www.ietf.org/mailman/listinfo/idr

 

 = 

______________________________________________=
___________________________________________________________________________=

 
Ce message et ses pieces jointes peuvent conte=
nir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans au=
torisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pi=
eces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce mess=
age a ete altere, deforme ou falsifie. Merci.

 


This message and its attachments may contain c=
onfidential or privileged information that may be protected by law;


they should not be distributed, used or copied=
 without authorisation.


If you have received this email in error, plea=
se notify the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable=
 for messages that have been modified, changed or falsified.


Thank you.


______________________________________________=
___________________________________________________________________________=

 
Ce message et ses pieces jointes peuvent conte=
nir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans au=
torisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pi=
eces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce mess=
age a ete altere, deforme ou falsifie. Merci.

 


This message and its attachments may contain c=
onfidential or privileged information that may be protected by law;


they should not be distributed, used or copied=
 without authorisation.


If you have received this email in error, plea=
se notify the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable=
 for messages that have been modified, changed or falsified.


Thank you.


______________________________________________________________________=
___________________________________________________

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,
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 authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.iet= f.org/mailman/listinfo/idr
--_000_CF0FFB141009Cbdicksonverisigncom_-- From rraszuk@gmail.com Thu Jan 30 10:05:24 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C04BD1A0437 for ; Thu, 30 Jan 2014 10:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8v4UC7CbbUPa for ; Thu, 30 Jan 2014 10:05:15 -0800 (PST) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) by ietfa.amsl.com (Postfix) with ESMTP id D47E51A03E0 for ; Thu, 30 Jan 2014 10:05:14 -0800 (PST) Received: by mail-lb0-f178.google.com with SMTP id u14so2795293lbd.37 for ; Thu, 30 Jan 2014 10:05:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=t47kirMKaySEVDgPBVnUpGma2M+Wrlew0xbh7y5ST+A=; b=lrnvb8wx0UCe12zKkNITPVngrMitYddwCD9yvltYSKmc9nDGVSXLFk17rQtEZnXQjx 0s5fT729b+pw1gpfZfuyEJr5/Q8f7rcO1rm/zxk9HGSnbO4dFWtoJnpenKM4M41xjNAN xb0ZgZoOxBbMCRTa6v5RGFvdrMstID8SUy4WKxpDDSkTmsDeT8VZpOk9jHRvn/q8WrUI 7y1z/lucPLbUgz6SDtaWpwNnxaDHSAbuea3yVEEzfXwIt1pbHEE5q4SLNPXTzykSXkfP EYVTbGe3l2FPrGgOExAsqOSue7H6HuvesaB2Kq7xKQDFmzjxPkHcDbclyA4OWNIhxtyg 12eQ== MIME-Version: 1.0 X-Received: by 10.152.203.193 with SMTP id ks1mr10639055lac.0.1391105110551; Thu, 30 Jan 2014 10:05:10 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.112.118.42 with HTTP; Thu, 30 Jan 2014 10:05:10 -0800 (PST) In-Reply-To: References: <5EECE2EC-9406-4BDB-8AEB-ADD1B7ABB167@ericsson.com> Date: Thu, 30 Jan 2014 19:05:10 +0100 X-Google-Sender-Auth: 25ynAZ--vzC17K_tQ7-fXRhJvfw Message-ID: From: Robert Raszuk To: "Keyur Patel (keyupate)" Content-Type: multipart/alternative; boundary=001a113470d2f5b1d804f133e5e4 Cc: "bruno.decraene@orange.com" , "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 18:05:25 -0000 --001a113470d2f5b1d804f133e5e4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All, Do we really need to get stuck forever and worry about differences with both EoR and EoRR ? Would it be much simpler to define Begin_of_RIB BOR and End_of_RIB EOR (already defined in GR spec) and always use both when peers negotiate enhanced route refresh even for the initial update with GR or as response to RRQ ? Is there any case where EoRR has added meaning on top of otherwise sent EOR ? Maybe this questions comes late considering deployed implementations, but I guess it is better late then never :) Best, R. On Thu, Jan 30, 2014 at 6:38 PM, Keyur Patel (keyupate) wrote: > Hi Bruno, > > Agree with Jakob here. :) The Route Refresh could restart for various > reasons (and depending on implementations). In that scenario, it could > simply resend a BoRR again. The receiver side behavior doesn't change in > such a case. Upon a receipt of BoRR mark the routes stale and restart the > timer. > > Having said that implementations could log the receipt of such > back-to-back BoRRs or EoRRs for further analysis. But it doesn't look lik= e > a Bug. > > Regards, > Keyur > > From: Jakob Heitz > Date: Thu, 30 Jan 2014 17:26:12 +0000 > To: "bruno.decraene@orange.com" > Cc: Keyur Patel , "idr@ietf.org" > > Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh > > Then make it not a bug. > A second BoRR means the first one was aborted. The draft as it stands > already covers this case. > > -- > Jakob Heitz. > > > On Jan 30, 2014, at 8:43 AM, "bruno.decraene@orange.com" < > bruno.decraene@orange.com> wrote: > > Hi Keyur, > > > > Comments inlined #Bruno > > > > *From:* Keyur Patel (keyupate) [mailto:keyupate@cisco.com] > > *Sent:* Thursday, January 30, 2014 3:48 PM > *To:* DECRAENE Bruno IMT/OLN > *Cc:* idr@ietf.org > *Subject:* Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh > > > > Hi Bruno, > > > > Comments Inlined #Keyur. > > > > *From:* > *Date: *Thu, 30 Jan 2014 10:27:56 +0000 > *To: *Keyur Patel > *Cc: *"idr@ietf.org" > *Subject: *RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh > > > > Hi Keyur, > > > > Thanks for your reply. > > Your proposed new text, using NOTIFICATION only for syntax errors seems > much better to me. Thanks for the clarification. > > > > Ideally, in addition, I would prefer to have a text also covering other > types of errors. At least the violation of explicit statement in the draf= t. > E.g. for the following 2 MUST > > " Before the speaker starts a route refresh that is either initiated > > locally, or in response to a "normal route refresh request" from the > > peer, the speaker MUST send a BoRR message. After the speaker > > completes the re-advertisement of the entire Adj-RIB-Out to the peer, > > it MUST send an EoRR message." > > > > Regarding the first one, IMHO there is no harm if the MUST is not > enforced. One option may be :s/MUST/SHOULD; or a statement in =A7 "Error > handling" on how to handle this error (e.g. log and nothing else). > > Regarding the second one, I'd like to see a text specifying what should b= e > done when I receive two BoRR. E.g. > > -a- consider that the second BoRR should be considered as a EoRR+ BoRR > > -b- ignore/abort the first EoRR procedure (i.e. remark all routes as STAL= E > when the second EoRR is received) > > -c- ignore the second EoRR. > > > > #Keyur: If the sender has sent two BoRRs (without an EoRR) then it means > it has aborted the first route refresh table announcement and restarted t= he > route refresh table announcement. The second EoRR will be essentially no-= op > (I.e C case). Implementations can log the no-op behavior. > > #Bruno : well we don't really know what it means for the sender because i= t > was not supposed to do this in the first place, so it's a bug. > > Ok for your proposition to ignore the second EoRR. Would it be possible t= o add this sentence/point in the =A7 "Error handling?" Especially since thi= s seems to contradict the spec which seems more on the side of "b": "When > > a BGP speaker receives a BoRR message from a peer, it MUST mark all > > the routes with the given from that peer as stale." > > Thanks, > > Regards, > > Bruno > > > > Regards, > > Keyur > > > > (plus obviously log the error in all cases) > > > > "a" sounds dangerous to me. > > "b" should a priori ok (accept a small error but consider that the speake= r > remember (and acted as per) its latest message.) > > "c" is the safest path (there is a error, I don't know what it is so I > take the safest option) > > > > Considering the motivation for this draft (enhance BGP robustness, but no= t > bring a new feature), I think I would prefer "c" which is the more robust= . > Especially given that if the receiver has a doubt, I has a way to clear i= t > by sending a new Route Refresh message. > > But I guess I would be fine with "b" if you/the WG have a different > opinion. > > (My understanding of the current draft, is that "b" is expected, but in > all cases I would prefer a specific text in =A7 "Error handling") > > > > Thanks, > > Cheers, > > Bruno > > > > > > *From:* Keyur Patel (keyupate) [mailto:keyupate@cisco.com] > > *Sent:* Wednesday, January 29, 2014 11:16 PM > *To:* DECRAENE Bruno IMT/OLN; Robert Raszuk > *Cc:* idr@ietf.org > *Subject:* Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh > > > > Hi Bruno, > > > > We only generate Notification for invalid length. Apologies for the > confusion. Attached is the revised text. > > > > Regards, > > Keyur > > > > > > The error handling specified in this section is applicable only when > > a BGP speaker has received the "Enhanced Route Refresh Capability" > > from a peer. > > > > If the length, excluding the fixed-size message header, of the > > received ROUTE-REFRESH message with Message Subtype 1 and 2 is not 4, > > then the BGP speaker MUST send a NOTIFICATION message with the Error > > Code of "ROUTE-REFRESH Message Error" and the subcode of "Invalid > > Message Length". The Data field of the NOTIFICATION message MUST > > contain the complete ROUTE-REFRESH message. > > > > When the BGP speaker receives a ROUTE-REFRESH message with a "Message > > Subtype" field other than 1 or 2, it MUST ignore the received ROUTE- > > REFRESH message. It SHOULD log an error for further analysis. > > > > > > > > *From: * > *Date: *Wed, 29 Jan 2014 09:51:00 +0000 > *To: *Robert Raszuk , Keyur Patel > *Cc: *"idr@ietf.org" > *Subject: *RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh > > > > Hi all, > > > > > > *From:* Idr [mailto:idr-bounces@ietf.org ] *On > Behalf Of *Robert Raszuk > *Sent:* Wednesday, January 29, 2014 10:15 AM > *To:* Dongjie (Jimmy) > *Cc:* Keyur Patel (keyupate); idr@ietf.org > *Subject:* Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh > > > > Hi Jimmy and all, > > > > I think Enke and Keyur's proposed text with help from Jakob makes the > behavior simplified and deterministic to hold on BoRR till first EoR is > seen. > > > > IMHO it should be also spelled out what is the expected sequence error > handling here > > > > [Bruno] +1. And taking into account possible interaction with > draft-ietf-idr-bgp-gr-notification > > > > BTW: > > "When the BGP speaker detects an error while processing a ROUTE-REFRESH > message with a non-zero "Message Subtype" field, it MUST send a > NOTIFICATION message with Error Code "ROUTE-REFRESH Message Error"." > > > > Seems a priori not inline with the recommendation from > draft-ietf-grow-ops-reqs-for-bgp-error-handling (which is to limit the > consequences of error handling). Are we sure that no error condition coul= d > be handled in a more friendly way? (e.g. if BoRR is not sent following a > "normal route refresh request" or if 2 BoRR are sent consecutively...) > > > > Thanks, > > Regards, > > Bruno > > > > > > ... I think not following "MUST NOT" shall implicitly result in entire > session drop and complete restart ? Any error code ? > > > > Best, > R. > > > > > > On Wed, Jan 29, 2014 at 9:22 AM, Dongjie (Jimmy) > wrote: > > Hi Robert, > > > > Agree that in these cases the RRQ cannot be ignored, so postpone may be a > better choice. > > > > While IMO stop the initial update and start over may delay the initial > convergence, and as you said it also relates to update group processing. > What do you think about the new text provided by Keyur? > > > > Best regards, > > Jie > > > > *From:*rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Robert > Raszuk > *Sent:* Sunday, January 26, 2014 11:03 PM > *To:* Dongjie (Jimmy) > *Cc:* Keyur Patel (keyupate); Jakob Heitz; idr@ietf.org > > > *Subject:* Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh > > > > Hi Jie, > > > > I think it actually very easy to say that initial update can not ever > guarantee that RRQ received during its sending may meet the peer's need. > > > > Example 1: > > > > SAFI 128 - During receiving initial update from RR to PE new VRF got adde= d > with new RT import. Unfortunately those updates received within initial > update were already dropped as not interesting by the PE. RR must resend > full table after completed initial update. (Of course this is the case > where there is no RTC and that's why RTC helps a lot here by incremental > nature). > > > > Example 2: > > > > SAFI 1 - Operator has modified inbound policy on EBGP peer during > processing of incoming updates and those originally were dropped. No soft > reconfig in set. > > > > Conclusion: > > > > RRQ can not ever be ignored. Sure they can be delayed or batched (case of > multiple peers within the same update/peer group) sending near RRQs > (cluster of PEs got provisioned from central management station). But as > Keyur already mentioned those are rather standard local implementation > optimizations. > > > > Question: > > > > Does it maybe make sense to stop initial update when receiving RRQ from a > peer and start over ? Of course if peer is part of large update group it > would have to be removed dynamically from it so other members are not > delayed. In any case I think this does not impact the spec but the > implementation. > > > > Cheers, > R. > > > > > > > > On Sun, Jan 26, 2014 at 7:13 PM, Dongjie (Jimmy) > wrote: > > Hi Keyur, Jakob, > > Agree that "postpone" may be better. The point is we could avoid the > complicated cases/considerations of performing route refresh during initi= al > update:) > > For "ignore", I was thinking of scenarios in which the route refresh > requirement may already be met by the initial update, while I'd admit it = is > hard to say... > > > > Best regards, > Jie > > -----Original Message----- > > From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] > Sent: Sunday, January 26, 2014 8:30 PM > To: Jakob Heitz; Dongjie (Jimmy) > Cc: idr@ietf.org > Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh > > Jie, > > I agree with Jakob. You could make it *an implementation behavior* to > postpone the route refresh reply. > > > Regards, > Keyur > > On 1/26/14 1:29 AM, "Jakob Heitz" wrote: > > >You can definitely not ignore it, but you could postpone it. > > > >-- > >Jakob Heitz. > > > >> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" > >>wrote: > >> > >> After reading the analyses in this thread, my personal feeling is > >>maybe we should avoid the interleaving between GR initial update and > >>route refresh/enhanced route refresh, since the initial update is just > >>sending the whole Adj-RIB-Out, there is no obvious advantage to start > >>a route refresh/enhance route refresh during it. So a speaker should > >>ignore the RRQ received during the initial update. Thoughts? > >> > >> Best regards, > >> Jie > >> > >> -----Original Message----- > >> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz > >> Sent: Saturday, January 25, 2014 10:48 PM > >> To: Chris Hall; idr@ietf.org > >> Subject: Re: [Idr] WG LC for > >> draft-ietf-idr-bgp-enhanced-route-refresh > >> > >> RFCs are written for coders "practiced" in the art". > >> If anyone sends an EoRR before the adj-RIB-out is fully populated, > >>then it's a BUG. > >> This does not need to be said. > >> > >> Personally, I believe a route refresh request should not be honored > >>until GR is complete. > >> Also, I don't believe a timer for the receipt of EoRR is necessary, > >>because the EoRR is guaranteed. > >> Guaranteed means "unless the session drops first". > >> -- > >> > >> Jakob Heitz. > >> > >> ________________________________________ > >> From: Chris Hall [chris.hall@highwayman.com] > >> Sent: Saturday, 25 January 2014 11:27 AM > >> To: idr@ietf.org > >> Cc: Jakob Heitz > >> Subject: RE: [Idr] WG LC for > >> draft-ietf-idr-bgp-enhanced-route-refresh > >> > >> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): > >> ... > >>> Silence means don't do it. > >> > >> Hmmm.... as a principle I'm more comfortable with "that which isn't > >>prohibited is permitted".... > >> > >>> You would definitely NOT want BoRR to flush old stales. > >> > >> ....but, given the definite requirement, and given that the current > >>precedent for "marking stale" does flush old stale, then a few words > >>for the avoidance of doubt ? > >> > >>> Restarting the timer might be a good idea. > >> > >> I dunno... a route which remains stale for "a long time" is, of > >>course, a candidate for being withdrawn: so having started a timer the > >>first time things are set stale, I would avoid extending that -- at > >>least for Graceful Restart, where the whole withdraw thing has been > "on-hold" > >>since the last session failed. For route-refresh I guess there's more > >>of a presumption that stale routes will be refreshed sooner or later, > >>and in the meantime they remain good. So if the route-refresh is > >>(repeatedly) restarted for some reason, perhaps it is more reasonable > >>to extend the flush deadline -- but avoid doing this indefinitely ? > >> > >> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I have > >>built in Quagga prioritise route changes (pending changes and any that > >>occur during the refresh) over refresh updates. This makes it more > >>likely that remaining stale routes are still good. But the other end > >>cannot know that. > >> > >> The paragraph in the draft discussing the "entire Adj-RIB-Out" > >>defines that to be the entries present "at the start of the route > >>refresh operation", and observes that these comprise both reachable > >>and unreachable routes. [An "of" after "comprise" sets teeth on edge, > >>BTW.] I'm really not sure what this paragraph is trying to tell me. > >> The reference to unreachable routes appears to suggest that pending > >>withdraws should be sent as part of the refresh -- so not left to the > >>EoRR to implement at the end. The point at which the EoRR is sent is > >>defined such that it excludes any Adj-RIB-Out entries added after the > >>route-refresh started, but includes any which are changed during the > >>process. It seems reasonable to delay any brand new reachable > >>prefixes until after all previously announced ones have been refreshed > >>and the EoRR sent -- if that's the intent here. Changes which occur > >>before the refresh gets to a given entry are pretty naturally swept up > >>by the refresh. Changes which occur after the refresh has gone past, > >>could/should be deferred to after the EoRR ? Does it make a > >>difference if the change is a withdraw ? (Of course MRAI may kick in > here. Ah. > >>MRAI and route-refresh, there's a topic !) > >> > >> I think the essence of the rule is that the EoRR should be sent once > >>all prefixes previously advertised to the peer as reachable have been > >>refreshed, ie announced or withdrawn (at least) once. Or, perhaps > >>more strictly, not *before* those prefixes have *all* been announced > >>once -- given that the EoRR will promptly bang un-advertised stuff on > the head. > >>Even more strictly perhaps: not send EoRR *before* any withdraws > >>implied by it are required or desirable. > >> > >> Depending on the implementation, a given sender may or may not be > >>able to determine the minimum set of updates required before sending > EoRR. > >> > >> If the refresh operation takes a long time, there may be good > >>routeing reasons to arrange for some route changes to be sent to the > peer "early" > >>-- that is to send announcements which do not contribute to the > >>refresh, but which are important enough to warrant delaying the end of > >>the refresh. That could be a matter for recommendation(s) in the > standard. > >> > >> NB: given that the timing of the EoRR is tied to the state of the > >>Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. At > >>the beginning of the initial update, the Restarting and Receiving > >>speakers have: > >> > >> Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out > >> > >> Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In > >> > >> Now suppose (bonkers or otherwise) the receiving speaker sends an RRQ > >>part way through the initial update. The restarting speaker responds > >>with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specification= . > >> The receiving speaker sees the EoRR, and flushes stale. > >>Unfortunately, if the restarting speaker has not yet fully populated > >>its Adj-RIB-Out, then many further routes will be sent before the EoR > >>falls due -- but the receiving speaker has already flushed their tiny > >>posteriors :-( > >> > >> I am coming to the view that route-refresh during a Graceful Restart > >>initial update is a horse of a different colour altogether. > >> > >> [So the assumption that EoRR and EoR are triggered by the same thing > >>was completely wrong, and I apologise for it.] > >> > >> Chris > >> > >> _______________________________________________ > >> 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 > > > > > > _________________________________________________________________________= ________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > > Thank you. > > _______________________________________________________________________= __________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > > Thank you. > > _______________________________________________________________________= __________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > _______________________________________________ > 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 > > --001a113470d2f5b1d804f133e5e4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
All,

Do we really need to get stuck forever and worry about differences with bot= h EoR and EoRR ? 

Would it be much simpler to define Begin_of_RIB BOR and End_of_RIB EOR (alr= eady defined in GR spec) and always use both when peers negotiate enhanced = route refresh even for the initial update with GR or as response to RRQ ?&n= bsp;

Is there any case where EoRR has adde= d meaning on top of otherwise sent EOR ? 

Maybe this questions comes late consi= dering deployed implementations, but I guess it is better late then never := ) 

Best,
R.


On Thu, Jan 30, 2014 at 6:38 PM, Keyur P= atel (keyupate) <keyupate@cisco.com> wrote:
Hi Bruno,

Agree with Jakob here. :) The Route Refresh could restart for var= ious reasons (and depending on implementations). In that scenario, it could= simply resend a BoRR again. The receiver side behavior doesn't change = in such a case. Upon a receipt of BoRR mark the routes stale and restart the timer.

Having said that implementations could log the receipt of such back-to= -back BoRRs or EoRRs for further analysis. But it doesn't look like a B= ug.

Regards,
Keyur

From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Thu, 30 Jan 2014 17:26:12 +00= 00
To: "bruno.decraene@orange.com" &= lt;bruno.dec= raene@orange.com>
Cc: Keyur Patel <keyupate@cisco.com>, "= idr@ietf.org" &l= t;idr@ietf.org>

Subject: Re: [Idr] WG LC for draft-= ietf-idr-bgp-enhanced-route-refresh

Then make it not a bug.
A second BoRR means the first one was aborted. The draft as it stands = already covers this case.

--
Jakob Heitz.


On Jan 30, 2014, at 8:43 AM, "bruno.decraene@orange.com" <bruno.decraene@orange.co= m> wrote:

H= i Keyur,

<= u> 

C= omments inlined #Bruno

=  

From:<= font face=3D"Tahoma"> Keyur Patel (keyupate) [= mailto:keyupate@cisco.com]
Sent: Thursday, January 30, = 2014 3:48 PM
To: DECRAENE Bruno IMT/OLN Cc: idr@ietf.org
Subject: Re: [Idr] WG LC for= draft-ietf-idr-bgp-enhanced-route-refresh

 

Hi Bruno,

 

Comments Inlined #Keyu= r.

 

From:<= /span><bruno.decraene@orange.com>
Date: Thu, 30 Jan 2014 10:27= :56 +0000
To: Keyur Patel <keyupate@cisco.com>=
Cc: "idr@ietf.org" <idr@ietf.org>
Subject: RE: [Idr] WG LC for= draft-ietf-idr-bgp-enhanced-route-refresh

 

Hi Keyur,

 <= u>

Thanks for your reply.

Your proposed new text, using NOTIFICATION only for syntax err= ors seems much better to me. Thanks for the clarification.

 <= u>

Ideally, in addition, I would prefer to have a text also cover= ing other types of errors. At least the violation of explicit statement in the draft. E.g. for the fo= llowing 2 MUST

&ldq= uo;   Before the speaker starts a route refresh that is either in= itiated

&nbs= p;  locally, or in response to a "normal route refresh request&qu= ot; from the<= /span>

&nbs= p;  peer, the speaker MUST send a BoRR message.  Af= ter the speaker

&nbs= p;  completes the re-advertisement of the entire Adj-RIB-Out to the pe= er,

&nbs= p;  it MUST send an EoRR message.”<= /span>=

 <= u>

Regarding the first one, IMHO there is no harm if the MUST is = not enforced. One option may be :s/MUST/SHOULD; or a statement in =A7 “Error handling” = on how to handle this error (e.g. log and nothing else).

Regarding the second one, I’d like to see a text specify= ing what should be done when I receive two BoRR. E.g.<= /u>

-a- consider that the second BoRR should be considered as a Eo= RR+ BoRR

-b- ignore/abort the first EoRR procedure (i.e. remark all rou= tes as STALE when the second EoRR is received)

-c- ignore the second EoRR.

 <= u>

#Keyur: I= f the sender has sent two BoRRs (without an EoRR) then it means it has abor= ted the first route refresh table announcement and restarted the route refresh table ann= ouncement. The second EoRR will be essentially no-op (I.e C case). Implementations can log the no-op= behavior.

#Bruno : well we don’t really know what it means = for the sender because it was not supposed to do this in the first place, so it’s a bug.

Ok f=
or your proposition to ignore the second EoRR. Would it be possible to add =
this sentence/point in the =A7 “Error handling?” Especially sin=
ce this seems to contradict the spec  which seems more on the side of =
“b”: “When

   a BGP s= peaker receives a BoRR message from a peer, it MUST mark all<= /span>

   the rou= tes with the given <AFI, SAFI> from that peer as stale.”=

Thanks,

Regards,

Bruno 

&n= bsp;

Regards,<= u>

Keyur<= /u>

 =

(plus obviously log the error in all cases)

 

“a” sounds dangerous to me.

“b” should a priori ok (accept a small error but c= onsider that the speaker remember (and acted as per) its latest message.)

“c” is the safest path (there is a error, I don&rs= quo;t know what it is so I take the safest option)

 <= u>

Considering the motivation for this draft (enhance BGP robustn= ess, but not bring a new feature), I think I would prefer “c” which is the more robust.= Especially given that if the receiver has a doubt, I has a way to clear it= by sending a new Route Refresh message.

But I guess I would be fine with “b” if you/the WG= have a different opinion.<= u>

(My understanding of the current draft, is that “b&rdquo= ; is expected, but in all cases I would prefer a specific text in  =A7 “Error handling”)

 <= u>

Thanks,=

Cheers,=

Bruno

&nb= sp;

&nb= sp;

From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com]
Sent: Wednesday, January 29,= 2014 11:16 PM
To: DECRAENE Bruno IMT/OLN; = Robert Raszuk
Cc: idr@ietf.org
Subject: Re: [Idr] WG LC for= draft-ietf-idr-bgp-enhanced-route-refresh

 

Hi Bruno,

 

We only generate Notif= ication for invalid length. Apologies for the confusion. Attached is the re= vised text.

 

Regards,=

Keyur

 

<snip>

The error handling spe= cified in this section is applicable only when

   a BGP spe= aker has received the "Enhanced Route Refresh Capability"<= /font>

   from a pe= er.

 

   If the le= ngth, excluding the fixed-size message header, of the

   received = ROUTE-REFRESH message with Message Subtype 1 and 2 is not 4,<= font color=3D"black">

   then the = BGP speaker MUST send a NOTIFICATION message with the Error

   Code of &= quot;ROUTE-REFRESH Message Error" and the subcode of "Invalid

   Message L= ength".  The Data field of the NOTIFICATION message MUST

   contain t= he complete ROUTE-REFRESH message.

 

   When the = BGP speaker receives a ROUTE-REFRESH message with a "Message

   Subtype&q= uot; field other than 1 or 2, it MUST ignore the received ROUTE-

   REFRESH m= essage.  It SHOULD log an error for further analysis.

 

<snip>

 

From: <bruno.decraene@orange.com>
Date: Wed, 29 Jan 2014 09:51= :00 +0000
To: Robert Raszuk <robert@raszuk.net>,= Keyur Patel <ke= yupate@cisco.com>
Cc: "idr@ietf.org" <idr@ietf.org>
Subject: RE: [Idr] WG LC for= draft-ietf-idr-bgp-enhanced-route-refresh

 

Hi = all,

&nb= sp;

&nb= sp;

From: Idr [mailto:idr-= bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Wednesday, January 29,= 2014 10:15 AM
To: Dongjie (Jimmy)
Cc: Keyur Patel (keyupate); = idr@ietf.org
Subject: Re: [Idr] WG LC for= draft-ietf-idr-bgp-enhanced-route-refresh

 <= u>

Hi Jimmy= and all,

 <= /p>

I think = Enke and Keyur's proposed text with help from Jakob makes the behavior = simplified and deterministic to hold on BoRR till first EoR is seen.

 <= /p>

IMHO it = should be also spelled out what is the expected sequence error handling her= e

&nb= sp;

[Bruno] +1.  And taking into account possible interaction= with draft-ietf-idr-bgp-gr-notification

 <= u>

BTW= :

“When the BGP speaker detects an error while processing = a ROUTE-REFRESH message with a non-zero "Message Subtype" field, it MUST send a NOTIFICATION me= ssage with Error Code "ROUTE-REFRESH Message Error".”

 <= u>

Seems a priori not inline with the recommendation from draft-i= etf-grow-ops-reqs-for-bgp-error-handling (which is to limit the consequences of error handling). Are we sure that n= o error condition could be handled in a more friendly way? (e.g. if BoRR is= not sent following a “normal route refresh request” or if 2 Bo= RR are sent consecutively…)

 <= u>

Thanks,=

Regards,

Bruno

 <= u>

 <= u>

... I think not following "MUST NOT" = shall implicitly result in entire session drop and complete restart ? Any e= rror code ?

 <= /p>

Best, R.

 <= /p>

 = ;

On Wed, Jan 29, 2014 at 9:22 AM, Don= gjie (Jimmy) <j= ie.dong@huawei.com> wrote:

Hi Robert,

 

Agree that in these cases the RRQ cannot be ignored, so postpone may be a better choice.

 

While IMO stop the initial update and start over may delay the initial convergence, and as you said &= nbsp;it also relates to update group processing. What do you think about th= e new text provided by Keyur?

 

Best rega= rds,

Jie

 

From:rraszuk@gmail.com [mailto:rraszuk@gma= il.com] On Behalf Of Robert Raszuk Sent: Sunday, January 26, 20= 14 11:03 PM
To: Dongjie (Jimmy)
Cc: Keyur Patel (keyupate); = Jakob Heitz; idr@ietf.org


Subject: Re: [Idr] WG LC for= draft-ietf-idr-bgp-enhanced-route-refresh

 <= u>

Hi Jie,

 =

I think it actually very easy to say that initial update can not ever guarantee that RRQ received during its sending= may meet the peer's need.

 =

Example 1:=

 =

SAFI 128 - During receiving initial update from RR to PE new VRF got added with new RT import. Unfortunately those up= dates received within initial update were already dropped as not interestin= g by the PE. RR must resend full table after completed initial update. (Of = course this is the case where there is no RTC and that's why RTC helps a lot here by incremental nature).&= nbsp;<= /font>

 =

Example 2: <= /u>

 =

SAFI 1 - Operator has modified inbound policy on EBGP peer during processing of incoming updates and those originally we= re dropped. No soft reconfig in set. 

 =

Conclusion:

 =

RRQ can not ever be ignored. Sure they can be delayed or batched (case of multiple peers within the same update/peer = group) sending near RRQs (cluster of PEs got provisioned from central manag= ement station). But as Keyur already mentioned those are rather standard lo= cal implementation optimizations. =

 =

Question:<= /u>

 =

Does it maybe make sense to stop initial update when receiving RRQ from a peer and start over ? Of course if peer is part = of large update group it would have to be removed dynamically from it so ot= her members are not delayed. In any case I think this does not impact the s= pec but the implementation.=

 =

Cheers,
R.

 =

 =

 <= u>

On Sun, Jan 26, 2014 = at 7:13 PM, Dongjie (Jimmy) <jie.dong@huawei.com> wrote:

Hi Keyur, Jakob,

Agree that "postpone" may be better. The point is we could avoid = the complicated cases/considerations of performing route refresh during ini= tial update:)

For "ignore", I was thinking of scenarios in which the route refr= esh requirement may already be met by the initial update, while I'd adm= it it is hard to say...



Best regards,
Jie

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

From: Keyur Patel (ke= yupate) [mailto:key= upate@cisco.com]
Sent: Sunday, January 26, 2014 8:30 PM
To: Jakob Heitz; Dongjie (Jimmy)
Cc: idr@ietf.org
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Jie,

I agree with Jakob. You could make it *an implementation behavior* to postp= one the route refresh reply.


Regards,
Keyur

On 1/26/14 1:29 AM, "Jakob Heitz" <jakob.heitz@ericsson.com> wrote:<= br>
>You can definitely not ignore it, but you could postpone it.
>
>--
>Jakob Heitz.
>
>> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" <jie.dong@huawei.com>
>>wrote:
>>
>> After reading the analyses in this thread, my personal feeling is<= br> >>maybe we should avoid the interleaving between GR initial update an= d
>>route refresh/enhanced route refresh, since the initial update is j= ust
>>sending the whole Adj-RIB-Out, there is no obvious advantage to sta= rt
>>a route refresh/enhance route refresh during it. So a speaker shoul= d
>>ignore the RRQ received during the initial update. Thoughts?
>>
>> Best regards,
>> Jie
>>
>> -----Original Message-----
>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz
>> Sent: Saturday, January 25, 2014 10:48 PM
>> To: Chris Hall; = idr@ietf.org
>> Subject: Re: [Idr] WG LC for
>> draft-ietf-idr-bgp-enhanced-route-refresh
>>
>> RFCs are written for coders "practiced" in the art"= .
>> If anyone sends an EoRR before the adj-RIB-out is fully populated,=
>>then it's a BUG.
>> This does not need to be said.
>>
>> Personally, I believe a route refresh request should not be honore= d
>>until GR is complete.
>> Also, I don't believe a timer for the receipt of EoRR is neces= sary,
>>because the EoRR is guaranteed.
>> Guaranteed means "unless the session drops first".
>> --
>>
>> Jakob Heitz.
>>
>> ________________________________________
>> From: Chris Hall [chris.hall@highwayman.com]
>> Sent: Saturday, 25 January 2014 11:27 AM
>> To: idr@ietf.org=
>> Cc: Jakob Heitz
>> Subject: RE: [Idr] WG LC for
>> draft-ietf-idr-bgp-enhanced-route-refresh
>>
>> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37):
>> ...
>>> Silence means don't do it.
>>
>> Hmmm.... as a principle I'm more comfortable with "that w= hich isn't
>>prohibited is permitted"....
>>
>>> You would definitely NOT want BoRR to flush old stales.
>>
>> ....but, given the definite requirement, and given that the curren= t
>>precedent for "marking stale" does flush old stale, then = a few words
>>for the avoidance of doubt ?
>>
>>> Restarting the timer might be a good idea.
>>
>> I dunno... a route which remains stale for "a long time"= is, of
>>course, a candidate for being withdrawn: so having started a timer = the
>>first time things are set stale, I would avoid extending that -- at=
>>least for Graceful Restart, where the whole withdraw thing has been= "on-hold"
>>since the last session failed.  For route-refresh I guess ther= e's more
>>of a presumption that stale routes will be refreshed sooner or late= r,
>>and in the meantime they remain good.  So if the route-refresh= is
>>(repeatedly) restarted for some reason, perhaps it is more reasonab= le
>>to extend the flush deadline -- but avoid doing this indefinitely ?=
>>
>> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I ha= ve
>>built in Quagga prioritise route changes (pending changes and any t= hat
>>occur during the refresh) over refresh updates.  This makes it= more
>>likely that remaining stale routes are still good.  But the ot= her end
>>cannot know that.
>>
>> The paragraph in the draft discussing the "entire Adj-RIB-Out= "
>>defines that to be the entries present "at the start of the ro= ute
>>refresh operation", and observes that these comprise both reac= hable
>>and unreachable routes.  [An "of" after "compri= se" sets teeth on edge,
>>BTW.]  I'm really not sure what this paragraph is trying t= o tell me.
>> The reference to unreachable routes appears to suggest that pendin= g
>>withdraws should be sent as part of the refresh -- so not left to t= he
>>EoRR to implement at the end.  The point at which the EoRR is = sent is
>>defined such that it excludes any Adj-RIB-Out entries added after t= he
>>route-refresh started, but includes any which are changed during th= e
>>process.  It seems reasonable to delay any brand new reachable=
>>prefixes until after all previously announced ones have been refres= hed
>>and the EoRR sent -- if that's the intent here.  Changes w= hich occur
>>before the refresh gets to a given entry are pretty naturally swept= up
>>by the refresh.  Changes which occur after the refresh has gon= e past,
>>could/should be deferred to after the EoRR ?  Does it make a >>difference if the change is a withdraw ?  (Of course MRAI may = kick in here.  Ah.
>>MRAI and route-refresh, there's a topic !)
>>
>> I think the essence of the rule is that the EoRR should be sent on= ce
>>all prefixes previously advertised to the peer as reachable have be= en
>>refreshed, ie announced or withdrawn (at least) once.  Or, per= haps
>>more strictly, not *before* those prefixes have *all* been announce= d
>>once -- given that the EoRR will promptly bang un-advertised stuff = on the head.
>>Even more strictly perhaps: not send EoRR *before* any withdraws >>implied by it are required or desirable.
>>
>> Depending on the implementation, a given sender may or may not be<= br> >>able to determine the minimum set of updates required before sendin= g EoRR.
>>
>> If the refresh operation takes a long time, there may be good
>>routeing reasons to arrange for some route changes to be sent to th= e peer "early"
>>-- that is to send announcements which do not contribute to the
>>refresh, but which are important enough to warrant delaying the end= of
>>the refresh.  That could be a matter for recommendation(s) in = the standard.
>>
>> NB: given that the timing of the EoRR is tied to the state of the<= br> >>Adj-RIB-Out, I'm not sure about the Graceful Restart assumption= s.  At
>>the beginning of the initial update, the Restarting and Receiving >>speakers have:
>>
>>  Restarting:  Empty Adj-RIB-In   Empty Adj-RIB-Out<= br> >>
>>  Receiving:   Empty Adj-RIB-Out  Stale Adj-RIB-In >>
>> Now suppose (bonkers or otherwise) the receiving speaker sends an = RRQ
>>part way through the initial update.  The restarting speaker r= esponds
>>with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specifica= tion.
>> The receiving speaker sees the EoRR, and flushes stale.
>>Unfortunately, if the restarting speaker has not yet fully populate= d
>>its Adj-RIB-Out, then many further routes will be sent before the E= oR
>>falls due -- but the receiving speaker has already flushed their ti= ny
>>posteriors :-(
>>
>> I am coming to the view that route-refresh during a Graceful Resta= rt
>>initial update is a horse of a different colour altogether.
>>
>> [So the assumption that EoRR and EoR are triggered by the same thi= ng
>>was completely wrong, and I apologise for it.]
>>
>> Chris
>>
>> _______________________________________________
>> 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
htt= ps://www.ietf.org/mailman/listinfo/idr

 <= u>

  

_____________________________________________________________________=
____________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations co=
nfidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous ave=
z recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les m=
essages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, defor=
me ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileg=
ed information that may be protected by law;


they should not be distributed, used or copied without authorisation.=



If you have received this email in error, please notify the sender an=
d delete this message and its attachments.


As emails may be altered, Orange is not liable for messages that have=
 been modified, changed or falsified.


Thank you.


_____________________________________________________________________=
____________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations co=
nfidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous ave=
z recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les m=
essages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, defor=
me ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileg=
ed information that may be protected by law;


they should not be distributed, used or copied without authorisation.=



If you have received this email in error, please notify the sender an=
d delete this message and its attachments.


As emails may be altered, Orange is not liable for messages that have=
 been modified, changed or falsified.


Thank you.


______________________________________________________________________=
___________________________________________________

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 message=
s electroniques etant susceptibles d'alteration,
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 authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

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


--001a113470d2f5b1d804f133e5e4-- From keyupate@cisco.com Thu Jan 30 10:20:27 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 373871A0072 for ; Thu, 30 Jan 2014 10:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.035 X-Spam-Level: X-Spam-Status: No, score=-15.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXIGEy2BtcSp for ; Thu, 30 Jan 2014 10:20:24 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 97FBA1A0260 for ; Thu, 30 Jan 2014 10:20:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21547; q=dns/txt; s=iport; t=1391106020; x=1392315620; h=from:to:cc:subject:date:message-id:mime-version; bh=ZF4/Es/b5t/hYE0k/5Il7ud0k1udQHJHkUItTrOU4AM=; b=TjfvO9U5N4tMGijSxKT3SdqVvxB5nt3SnlN71oAPCtSPc4T5KN5cIO4c CNGq0Rx6ZaTIK6aTU/lWhTP0L5SkTu4v8W2e4iqv+Loii2XYq6UPHAWBE nmHR6Kbt6uYbBHUc4z4xYN3xuiXJMazjcutPdzL3YwkfuE4USAyrHo/uH Y=; X-Files: draft-ietf-idr-bgp-enhanced-route-refresh-06.txt : 13967 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmgFAOeW6lKtJXHA/2dsb2JhbABZgkhEOFepXJNIgQwWdIIcEHkSAQsBRDAnBA4FDodjAxENzCIXjGyBNBEBJRAbCQKENASLUwIBhGiEAoF9gWuBMosshUGDLYFoAgUCFwYc X-IronPort-AV: E=Sophos;i="4.95,751,1384300800"; d="txt'?scan'208,217";a="300795807" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 30 Jan 2014 18:20:20 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s0UIKJGQ020393 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Jan 2014 18:20:19 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.228]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Thu, 30 Jan 2014 12:20:19 -0600 From: "Keyur Patel (keyupate)" To: "idr@ietf.org" Thread-Topic: draft-ietf-idr-bgp-enhanced-route-refresh-06.txt Thread-Index: AQHPHefuyl4e2PkcMUKSCY4dU5/Byw== Date: Thu, 30 Jan 2014 18:20:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [128.107.163.31] Content-Type: multipart/mixed; boundary="_004_CF0FD8F86170Bkeyupateciscocom_" MIME-Version: 1.0 Cc: Susan Hares Subject: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 18:20:27 -0000 --_004_CF0FD8F86170Bkeyupateciscocom_ Content-Type: multipart/alternative; boundary="_000_CF0FD8F86170Bkeyupateciscocom_" --_000_CF0FD8F86170Bkeyupateciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, Thank you all for detailed review of the document during the last call. I h= ave revised the draft as per the following WG Last call comments: - Clarified GR/EOR interaction with Enhanced Route Refresh. - Clarified the Error Handling text for Enhanced Route Refresh with Invali= d message subtypes. - Updated Author's information and Acknowledgement section. Best Regards, Keyur --_000_CF0FD8F86170Bkeyupateciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <8D3B7DDDB0C7244A8006B5F364052221@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Folks,

Thank you all for detailed review of the document during the last call= . I have revised the draft as per the following WG Last call comments:


-  Clarified GR/EOR interaction with Enhanced Route Refresh.

-  Clarified the Error Handling text for Enhanced Route Refresh w= ith Invalid message subtypes.

-  Updated Author's information and Acknowledgement section.



Best Regards,
Keyur

--_000_CF0FD8F86170Bkeyupateciscocom_-- --_004_CF0FD8F86170Bkeyupateciscocom_ Content-Type: text/plain; name="draft-ietf-idr-bgp-enhanced-route-refresh-06.txt" Content-Description: draft-ietf-idr-bgp-enhanced-route-refresh-06.txt Content-Disposition: attachment; filename="draft-ietf-idr-bgp-enhanced-route-refresh-06.txt"; size=13967; creation-date="Thu, 30 Jan 2014 18:20:18 GMT"; modification-date="Thu, 30 Jan 2014 18:20:18 GMT" Content-ID: <48632D6F0743C3469B497937A22D7160@emea.cisco.com> Content-Transfer-Encoding: base64 CgoKCklEUiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBLLiBQYXRlbApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEUuIENoZW4KSW50ZW5kZWQgc3RhdHVzOiBTdGFu ZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAgICBDaXNjbyBTeXN0ZW1zCkV4cGly ZXM6IEF1Z3VzdCAzLCAyMDE0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBCLiBWZW5rYXRh Y2hhbGFwYXRoeQoKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBKYW51YXJ5IDMwLCAyMDE0CgoKICAgICAgICAgICAgICBFbmhhbmNlZCBSb3V0 ZSBSZWZyZXNoIENhcGFiaWxpdHkgZm9yIEJHUC00CiAgICAgICAgICAgIGRyYWZ0LWlldGYtaWRy LWJncC1lbmhhbmNlZC1yb3V0ZS1yZWZyZXNoLTA2LnR4dAoKQWJzdHJhY3QKCiAgIEluIHRoaXMg ZG9jdW1lbnQgd2UgZW5oYW5jZSB0aGUgZXhpc3RpbmcgQkdQIHJvdXRlIHJlZnJlc2ggbWVjaGFu aXNtcwogICB0byBwcm92aWRlIGZvciB0aGUgZGVtYXJjYXRpb24gb2YgdGhlIGJlZ2lubmluZyBh bmQgdGhlIGVuZGluZyBvZiBhCiAgIHJvdXRlIHJlZnJlc2guICBUaGUgZW5oYW5jZW1lbnQgY2Fu IGJlIHVzZWQgdG8gZmFjaWxpdGF0ZSBjb3JyZWN0aW9uCiAgIG9mIEJHUCBSSUIgaW5jb25zaXN0 ZW5jaWVzIGluIGEgbm9uLWRpc3J1cHRpdmUgbWFubmVyLgoKU3RhdHVzIG9mIFRoaXMgTWVtbwoK ICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3 aXRoIHRoZQogICBwcm92aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5LgoKICAgSW50ZXJuZXQt RHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcK ICAgVGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRp c3RyaWJ1dGUKICAgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxp c3Qgb2YgY3VycmVudCBJbnRlcm5ldC0KICAgRHJhZnRzIGlzIGF0IGh0dHA6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kcmFmdHMvY3VycmVudC8uCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0 IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMKICAgYW5kIG1heSBi ZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBh bnkKICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBh cyByZWZlcmVuY2UKICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndv cmsgaW4gcHJvZ3Jlc3MuIgoKICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBB dWd1c3QgMywgMjAxNC4KCkNvcHlyaWdodCBOb3RpY2UKCiAgIENvcHlyaWdodCAoYykgMjAxNCBJ RVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZQogICBkb2N1bWVudCBh dXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4KCiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVj dCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWwKICAgUHJvdmlzaW9ucyBSZWxh dGluZyB0byBJRVRGIERvY3VtZW50cwogICAoaHR0cDovL3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5z ZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2YKICAgcHVibGljYXRpb24gb2YgdGhpcyBk b2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzCiAgIGNhcmVmdWxseSwgYXMg dGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJpY3Rpb25zIHdpdGggcmVzcGVjdAog ICB0byB0aGlzIGRvY3VtZW50LiAgQ29kZSBDb21wb25lbnRzIGV4dHJhY3RlZCBmcm9tIHRoaXMg ZG9jdW1lbnQgbXVzdAogICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UgdGV4dCBhcyBk ZXNjcmliZWQgaW4gU2VjdGlvbiA0LmUgb2YKCgoKClBhdGVsLCBldCBhbC4gICAgICAgICAgICBF eHBpcmVzIEF1Z3VzdCAzLCAyMDE0ICAgICAgICAgICAgICAgICBbUGFnZSAxXQoMCkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEphbnVh cnkgMjAxNAoKCiAgIHRoZSBUcnVzdCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQg d2l0aG91dCB3YXJyYW50eSBhcwogICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNEIExp Y2Vuc2UuCgpUYWJsZSBvZiBDb250ZW50cwoKICAgMS4gIEludHJvZHVjdGlvbiAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAyCiAgIDIuICBSZXF1aXJl bWVudHMgTGFuZ3VhZ2UgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAg MgogICAzLiAgUHJvdG9jb2wgRXh0ZW5zaW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgIDIKICAgICAzLjEuICBFbmhhbmNlZCBSb3V0ZSBSZWZyZXNoIENhcGFi aWxpdHkgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAzCiAgICAgMy4yLiAgU3VidHlwZXMgZm9y IFJPVVRFLVJFRlJFU0ggTWVzc2FnZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMwogICA0LiAg T3BlcmF0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgIDMKICAgNS4gIEVycm9yIEhhbmRsaW5nICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0CiAgIDYuICBJQU5BIENvbnNpZGVyYXRpb25zIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNQogICA3LiAgU2VjdXJpdHkg Q29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDYK ICAgOC4gIEFja25vd2xlZGdlbWVudHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gICA2CiAgIDkuICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNgogICBBdXRob3JzJyBBZGRyZXNzZXMgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDcKCjEuICBJbnRy b2R1Y3Rpb24KCiAgIEl0IGlzIHNvbWV0aW1lcyBuZWNlc3NhcnkgdG8gcGVyZm9ybSByb3V0aW5n IGNvbnNpc3RlbmN5IHZhbGlkYXRpb25zCiAgIHN1Y2ggYXMgY2hlY2tpbmcgZm9yIHBvc3NpYmxl IG1pc3Npbmcgd2l0aGRyYXdzIGJldHdlZW4gQkdQIHNwZWFrZXJzCiAgIFtSRkM0MjcxXS4gIEN1 cnJlbnRseSBzdWNoIHZhbGlkYXRpb25zIHR5cGljYWxseSBpbnZvbHZlIG9mZi1saW5lLAogICBt YW51YWwgb3BlcmF0aW9ucyB3aGljaCBjYW4gYmUgdGVkaW91cyBhbmQgdGltZSBjb25zdW1pbmcu CgogICBJbiB0aGlzIGRvY3VtZW50IHdlIGVuaGFuY2UgdGhlIGV4aXN0aW5nIEJHUCByb3V0ZSBy ZWZyZXNoIG1lY2hhbmlzbXMKICAgW1JGQzI5MThdIHRvIHByb3ZpZGUgZm9yIHRoZSBkZW1hcmNh dGlvbiBvZiB0aGUgYmVnaW5uaW5nIGFuZCB0aGUKICAgZW5kaW5nIG9mIGEgcm91dGUgcmVmcmVz aCAod2hpY2ggcmVmZXJzIHRvIHRoZSBjb21wbGV0ZSByZS0KICAgYWR2ZXJ0aXNlbWVudCBvZiB0 aGUgQWRqLVJJQi1PdXQgdG8gYSBwZWVyLCBzdWJqZWN0IHRvIHJvdXRpbmcKICAgcG9saWNpZXMp LiAgVGhlIGVuaGFuY2VtZW50IGNhbiBiZSB1c2VkIHRvIGZhY2lsaXRhdGUgb24tbGluZSwgbm9u LQogICBkaXNydXB0aXZlIGNvbnNpc3RlbmN5IHZhbGlkYXRpb24gb2YgQkdQIHJvdXRpbmcgdXBk YXRlcy4KCjIuICBSZXF1aXJlbWVudHMgTGFuZ3VhZ2UKCiAgIFRoZSBrZXkgd29yZHMgIk1VU1Qi LCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwKICAgIlNIT1VM RCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGFy ZSB0bwogICBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gW1JGQzIxMTldIG9ubHkgd2hl biB0aGV5IGFwcGVhciBpbiBhbGwKICAgdXBwZXIgY2FzZS4gIFRoZXkgbWF5IGFsc28gYXBwZWFy IGluIGxvd2VyIG9yIG1peGVkIGNhc2UgYXMgRW5nbGlzaAogICB3b3Jkcywgd2l0aG91dCBhbnkg bm9ybWF0aXZlIG1lYW5pbmcuCgozLiAgUHJvdG9jb2wgRXh0ZW5zaW9ucwoKICAgVGhlIEJHUCBw cm90b2NvbCBleHRlbnNpb25zIGludHJvZHVjZWQgaW4gdGhpcyBkb2N1bWVudCBpbmNsdWRlIHRo ZQogICBkZWZpbml0aW9uIG9mIGEgbmV3IEJHUCBjYXBhYmlsaXR5LCBuYW1lZCAiRW5oYW5jZWQg Um91dGUgUmVmcmVzaAogICBDYXBhYmlsaXR5IiwgYW5kIHRoZSBzcGVjaWZpY2F0aW9uIG9mIHRo ZSBtZXNzYWdlIHN1YnR5cGVzIGZvciB0aGUKICAgUk9VVEUtUkVGUkVTSCBtZXNzYWdlLgoKCgoK ClBhdGVsLCBldCBhbC4gICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAzLCAyMDE0ICAgICAgICAg ICAgICAgICBbUGFnZSAyXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEphbnVhcnkgMjAxNAoKCjMuMS4gIEVuaGFuY2VkIFJvdXRl IFJlZnJlc2ggQ2FwYWJpbGl0eQoKICAgVGhlICJFbmhhbmNlZCBSb3V0ZSBSZWZyZXNoIENhcGFi aWxpdHkiIGlzIGEgbmV3IEJHUCBjYXBhYmlsaXR5CiAgIFtSRkM1NDkyXS4gIElBTkEgaGFzIGFz c2lnbmVkIGEgQ2FwYWJpbGl0eSBDb2RlIG9mIDcwIGZvciB0aGlzCiAgIGNhcGFiaWxpdHkgLiBU aGUgQ2FwYWJpbGl0eSBMZW5ndGggZmllbGQgb2YgdGhpcyBjYXBhYmlsaXR5IGlzIHplcm8uCgog ICBCeSBhZHZlcnRpc2luZyB0aGlzIGNhcGFiaWxpdHkgdG8gYSBwZWVyLCBhIEJHUCBzcGVha2Vy IGNvbnZleXMgdG8KICAgdGhlIHBlZXIgdGhhdCB0aGUgc3BlYWtlciBzdXBwb3J0cyB0aGUgbWVz c2FnZSBzdWJ0eXBlcyBmb3IgdGhlCiAgIFJPVVRFLVJFRlJFU0ggbWVzc2FnZSBhbmQgdGhlIHJl bGF0ZWQgcHJvY2VkdXJlcyBkZXNjcmliZWQgaW4gdGhpcwogICBkb2N1bWVudC4KCjMuMi4gIFN1 YnR5cGVzIGZvciBST1VURS1SRUZSRVNIIE1lc3NhZ2UKCiAgIFRoZSAiUmVzZXJ2ZWQiIGZpZWxk IG9mIHRoZSBST1VURS1SRUZSRVNIIG1lc3NhZ2Ugc3BlY2lmaWVkIGluCiAgIFtSRkMyOTE4XSBp cyByZS1kZWZpbmVkIGFzIHRoZSAiTWVzc2FnZSBTdWJ0eXBlIiB3aXRoIHRoZSBmb2xsb3dpbmcK ICAgdmFsdWVzOgoKICAgICAgICAgIDAgLSBOb3JtYWwgcm91dGUgcmVmcmVzaCByZXF1ZXN0IFtS RkMyOTE4XQogICAgICAgICAgICAgICAgICB3aXRoL3dpdGhvdXQgT1JGIFtSRkM1MjkxXQogICAg ICAgICAgMSAtIERlbWFyY2F0aW9uIG9mIHRoZSBiZWdpbm5pbmcgb2YgYSByb3V0ZSByZWZyZXNo IG9wZXJhdGlvbi4KICAgICAgICAgICAgICBBbHNvIGtub3duIGFzIGEgIkJvUlIgbWVzc2FnZSIg b3IganVzdCBhICJCb1JSIi4KICAgICAgICAgIDIgLSBEZW1hcmNhdGlvbiBvZiB0aGUgZW5kaW5n IG9mIGEgcm91dGUgcmVmcmVzaCBvcGVyYXRpb24uCiAgICAgICAgICAgICAgQWxzbyBrbm93biBh cyBhICJFb1JSIG1lc3NhZ2UiIG9yIGp1c3QgYSAiRW9SUiIuCgogICBUaGUgcmVtYWluaW5nIHZh bHVlcyBvZiB0aGUgbWVzc2FnZSBzdWJ0eXBlcyBhcmUgcmVzZXJ2ZWQgZm9yIGZ1dHVyZQogICB1 c2UuICBUaGUgdXNlIG9mIHRoZSBuZXcgbWVzc2FnZSBzdWJ0eXBlcyBpcyBkZXNjcmliZWQgaW4g dGhlCiAgIE9wZXJhdGlvbnMgc2VjdGlvbi4KCjQuICBPcGVyYXRpb24KCiAgIEEgQkdQIHNwZWFr ZXIgdGhhdCBzdXBwb3J0cyB0aGUgbWVzc2FnZSBzdWJ0eXBlcyBmb3IgdGhlIFJPVVRFLQogICBS RUZSRVNIIG1lc3NhZ2UgYW5kIHRoZSByZWxhdGVkIHByb2NlZHVyZXMgU0hPVUxEIGFkdmVydGlz ZSB0aGUKICAgIkVuaGFuY2VkIFJvdXRlIFJlZnJlc2ggQ2FwYWJpbGl0eSIuCgogICBUaGUgZm9s bG93aW5nIHByb2NlZHVyZXMgYXJlIGFwcGxpY2FibGUgb25seSBpZiBhIEJHUCBzcGVha2VyIGhh cwogICByZWNlaXZlZCB0aGUgIkVuaGFuY2VkIFJvdXRlIFJlZnJlc2ggQ2FwYWJpbGl0eSIgZnJv bSBhIHBlZXIuCgogICBCZWZvcmUgdGhlIHNwZWFrZXIgc3RhcnRzIGEgcm91dGUgcmVmcmVzaCB0 aGF0IGlzIGVpdGhlciBpbml0aWF0ZWQKICAgbG9jYWxseSwgb3IgaW4gcmVzcG9uc2UgdG8gYSAi bm9ybWFsIHJvdXRlIHJlZnJlc2ggcmVxdWVzdCIgZnJvbSB0aGUKICAgcGVlciwgdGhlIHNwZWFr ZXIgTVVTVCBzZW5kIGEgQm9SUiBtZXNzYWdlLiAgQWZ0ZXIgdGhlIHNwZWFrZXIKICAgY29tcGxl dGVzIHRoZSByZS1hZHZlcnRpc2VtZW50IG9mIHRoZSBlbnRpcmUgQWRqLVJJQi1PdXQgdG8gdGhl IHBlZXIsCiAgIGl0IE1VU1Qgc2VuZCBhbiBFb1JSIG1lc3NhZ2UuCgogICBDb25jZXB0dWFsbHkg dGhlICJlbnRpcmUgQWRqLVJJQi1PdXQiIGZvciBhIHBlZXIgaW4gdGhpcyBzZWN0aW9uCiAgIHJl ZmVycyB0byBhbGwgdGhlIHJvdXRlIGVudHJpZXMgaW4gdGhlICJBZGotUklCLU91dCIgZm9yIHRo ZSBwZWVyIGF0CiAgIHRoZSBzdGFydCBvZiB0aGUgcm91dGUgcmVmcmVzaCBvcGVyYXRpb24uICBU aGVzZSByb3V0ZSBlbnRyaWVzCiAgIGNvbXByaXNlIG9mIGJvdGgsIHRoZSByZWFjaGFiaWxpdHkg YXMgd2VsbCBhcyB1bnJlYWNoYWJpbGl0eQoKCgoKUGF0ZWwsIGV0IGFsLiAgICAgICAgICAgIEV4 cGlyZXMgQXVndXN0IDMsIDIwMTQgICAgICAgICAgICAgICAgIFtQYWdlIDNdCgwKSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSmFudWFy eSAyMDE0CgoKICAgaW5mb3JtYXRpb24uICBXaGVuIGEgcm91dGUgZW50cnkgaW4gdGhlICJBREot UklCLU91dCIgY2hhbmdlcywgb25seQogICB0aGUgbW9kaWZpZWQgcm91dGUgZW50cnkgbmVlZHMg dG8gYmUgYWR2ZXJ0aXNlZC4KCiAgIEluIHByb2Nlc3NpbmcgYSBST1VURS1SRUZSRVNIIG1lc3Nh Z2UgZnJvbSBhIHBlZXIsIHRoZSBCR1Agc3BlYWtlcgogICBNVVNUIGV4YW1pbmUgdGhlICJtZXNz YWdlIHN1YnR5cGUiIGZpZWxkIG9mIHRoZSBtZXNzYWdlIGFuZCB0YWtlIHRoZQogICBhcHByb3By aWF0ZSBhY3Rpb25zLiAgVGhlIG1lc3NhZ2UgcHJvY2Vzc2luZyBydWxlcyBmb3IgUk9VVEUtUkVG UkVTSAogICBtZXNzYWdlIHdpdGggc3VidHlwZSBvZiAwIGFyZSBkZXNjcmliZWQgaW4gW1JGQzI5 MThdIGFuZCBbUkZDNTI5MV0uCiAgIEEgQkdQIHNwZWFrZXIgY2FuIHJlY2VpdmUgYSBCb1JSIG1l c3NhZ2UgZnJvbSBhIHBlZXIgYXQgYW55dGltZSwKICAgZWl0aGVyIGFzIGEgcmVzdWx0IG9mIGEg cGVlciByZXNwb25kaW5nIHRvIGEgUk9VVEUtUkVGRVNIIG1lc3NhZ2UsIG9yCiAgIGFzIGEgcmVz dWx0IG9mIGEgcGVlciB1bmlsYXRlcmFsbHkgaW5pdGlhdGluZyBhIHJvdXRlIHJlZnJlc2guICBX aGVuCiAgIGEgQkdQIHNwZWFrZXIgcmVjZWl2ZXMgYSBCb1JSIG1lc3NhZ2UgZnJvbSBhIHBlZXIs IGl0IE1VU1QgbWFyayBhbGwKICAgdGhlIHJvdXRlcyB3aXRoIHRoZSBnaXZlbiA8QUZJLCBTQUZJ PiBmcm9tIHRoYXQgcGVlciBhcyBzdGFsZS4gIEFzIGl0CiAgIHJlY2VpdmVzIHJvdXRlcyBmcm9t IGl0cyBwZWVyJ3Mgc3Vic2VxdWVudCBBZGotUklCLU91dCByZS0KICAgYWR2ZXJ0aXNlbWVudCwg dGhlc2UgcmVwbGFjZSBhbnkgY29ycmVzcG9uZGluZyBzdGFsZSByb3V0ZXMuICBXaGVuIGEKICAg QkdQIHNwZWFrZXIgcmVjZWl2ZXMgYW4gRW9SUiBtZXNzYWdlIGZyb20gYSBwZWVyLCBpdCBNVVNU IGltbWVkaWF0ZWx5CiAgIHJlbW92ZSBhbnkgcm91dGVzIGZyb20gdGhlIHBlZXIgdGhhdCBhcmUg c3RpbGwgbWFya2VkIGFzIHN0YWxlIGZvcgogICB0aGF0IDxBRkksIFNBRkk+LiAgU3VjaCBwdXJn ZWQgcm91dGVzIE1BWSBiZSBsb2dnZWQgZm9yIGZ1dHVyZQogICBhbmFseXNpcy4KCiAgIEFuIGlt cGxlbWVudGF0aW9uIE1BWSBpbXBvc2UgYSBsb2NhbGx5IGNvbmZpZ3VyYWJsZSB1cHBlciBib3Vu ZCBvbgogICBob3cgbG9uZyBpdCB3b3VsZCByZXRhaW4gYW55IHN0YWxlIHJvdXRlcy4gIE9uY2Ug dGhlIHVwcGVyIGJvdW5kIGlzCiAgIHJlYWNoZWQsIHRoZSBpbXBsZW1lbnRhdGlvbiBNQVkgcmVt b3ZlIGFueSByb3V0ZXMgZnJvbSB0aGUgcGVlciB0aGF0CiAgIGFyZSBzdGlsbCBtYXJrZWQgYXMg c3RhbGUgZm9yIHRoYXQgPEFGSSwgU0FGST4gd2l0aG91dCB3YWl0aW5nIGZvciBhbgogICBFb1JS IG1lc3NhZ2UuCgogICBUaGUgZm9sbG93aW5nIHByb2NlZHVyZXMgYXJlIHNwZWNpZmllZCBpbiBv cmRlciB0byBzaW1wbGlmeSB0aGUKICAgaW50ZXJhY3Rpb24gd2l0aCB0aGUgQkdQIEdyYWNlZnVs IFJlc3RhcnQgW1JGQzQ3MjRdLiAgRm9yIGEgQkdQCiAgIHNwZWFrZXIgdGhhdCBzdXBwb3J0cyB0 aGUgQkdQIEdyYWNlZnVsIFJlc3RhcnQsIGl0IE1VU1QgTk9UIHNlbmQgYQogICBCb1JSIGZvciBh biBBRkkvU0FGSSB0byBhIG5laWdoYm9yIGJlZm9yZSBpdCBzZW5kcyB0aGUgRU9SIGZvciB0aGUK ICAgQUZJL1NBRkkgdG8gdGhlIG5laWdoYm9yLiAgQSBCR1Agc3BlYWtlciB0aGF0IGhhcyByZWNl aXZlZCB0aGUKICAgR3JhY2VmdWwgUmVzdGFydCBDYXBhYmlsaXR5IGZyb20gaXRzIG5laWdoYm9y LCBNVVNUIGlnbm9yZSBhbnkgQm9SUnMKICAgZm9yIGFuIEFGSS9TQUZJIGZyb20gdGhlIG5laWdo Ym9yIGJlZm9yZSB0aGUgc3BlYWtlciByZWNlaXZlcyB0aGUgRW9SCiAgIGZvciB0aGUgZ2l2ZW4g QUZJL1NBRkkgZnJvbSB0aGUgbmVpZ2hib3IuICBUaGUgQkdQIHNwZWFrZXIgU0hPVUxEIGxvZwog ICBhbiBlcnJvciBvZiB0aGUgY29uZGl0aW9uIGZvciBmdXJ0aGVyIGFuYWx5c2lzLgoKNS4gIEVy cm9yIEhhbmRsaW5nCgogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBuZXcgTk9USUZJQ0FUSU9O IGVycm9yIGNvZGU6CgogICAgICAgIEVycm9yIENvZGUgICAgIFN5bWJvbGljIE5hbWUKCiAgICAg ICAgICAgIFRCRCAgICAgICAgUk9VVEUtUkVGUkVTSCBNZXNzYWdlIEVycm9yCgogICBUaGUgZm9s bG93aW5nIGVycm9yIHN1YmNvZGVzIGFyZSBkZWZpbmVkIGFzIHdlbGw6CgogICAgICAgICAgU3Vi Y29kZSAgICAgIFN5bWJvbGljIE5hbWUKCiAgICAgICAgICAgICAxICAgICAgICAgSW52YWxpZCBN ZXNzYWdlIExlbmd0aAoKCgpQYXRlbCwgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3Qg MywgMjAxNCAgICAgICAgICAgICAgICAgW1BhZ2UgNF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMTQKCgogICBU aGUgZXJyb3IgaGFuZGxpbmcgc3BlY2lmaWVkIGluIHRoaXMgc2VjdGlvbiBpcyBhcHBsaWNhYmxl IG9ubHkgd2hlbgogICBhIEJHUCBzcGVha2VyIGhhcyByZWNlaXZlZCB0aGUgIkVuaGFuY2VkIFJv dXRlIFJlZnJlc2ggQ2FwYWJpbGl0eSIKICAgZnJvbSBhIHBlZXIuCgogICBJZiB0aGUgbGVuZ3Ro LCBleGNsdWRpbmcgdGhlIGZpeGVkLXNpemUgbWVzc2FnZSBoZWFkZXIsIG9mIHRoZQogICByZWNl aXZlZCBST1VURS1SRUZSRVNIIG1lc3NhZ2Ugd2l0aCBNZXNzYWdlIFN1YnR5cGUgMSBhbmQgMiBp cyBub3QgNCwKICAgdGhlbiB0aGUgQkdQIHNwZWFrZXIgTVVTVCBzZW5kIGEgTk9USUZJQ0FUSU9O IG1lc3NhZ2Ugd2l0aCB0aGUgRXJyb3IKICAgQ29kZSBvZiAiUk9VVEUtUkVGUkVTSCBNZXNzYWdl IEVycm9yIiBhbmQgdGhlIHN1YmNvZGUgb2YgIkludmFsaWQKICAgTWVzc2FnZSBMZW5ndGgiLiAg VGhlIERhdGEgZmllbGQgb2YgdGhlIE5PVElGSUNBVElPTiBtZXNzYWdlIE1VU1QKICAgY29udGFp biB0aGUgY29tcGxldGUgUk9VVEUtUkVGUkVTSCBtZXNzYWdlLgoKICAgV2hlbiB0aGUgQkdQIHNw ZWFrZXIgcmVjZWl2ZXMgYSBST1VURS1SRUZSRVNIIG1lc3NhZ2Ugd2l0aCBhICJNZXNzYWdlCiAg IFN1YnR5cGUiIGZpZWxkIG90aGVyIHRoYW4gMSBvciAyLCBpdCBNVVNUIGlnbm9yZSB0aGUgcmVj ZWl2ZWQgUk9VVEUtCiAgIFJFRlJFU0ggbWVzc2FnZS4gIEl0IFNIT1VMRCBsb2cgYW4gZXJyb3Ig Zm9yIGZ1cnRoZXIgYW5hbHlzaXMuCgo2LiAgSUFOQSBDb25zaWRlcmF0aW9ucwoKICAgVGhpcyBk b2N1bWVudCBkZWZpbmVzIHRoZSBFbmhhbmNlZCBSb3V0ZSBSZWZyZXNoIENhcGFiaWxpdHkgZm9y IEJHUC4KICAgVGhlIENhcGFiaWxpdHkgQ29kZSA3MCBoYXMgYmVlbiBhc3NpZ25lZCBieSB0aGUg SUFOQS4gIFRoaXMgZG9jdW1lbnQKICAgYWxzbyBkZWZpbmVzIHR3byBuZXcgc3ViY29kZXMgZm9y IHRoZSBSb3V0ZSBSZWZyZXNoIG1lc3NhZ2UuICBUaGV5CiAgIG5lZWQgdG8gYmUgcmVnaXN0ZXJl ZCB3aXRoIHRoZSBJQU5BLiAgV2UgcmVxdWVzdCBJQU5BIHRvIGNyZWF0ZSBhIG5ldwogICByZWdp c3RyeSBmb3IgdGhlIFJvdXRlIFJlZnJlc2ggbWVzc2FnZSBzdWJjb2RlcyBhcyBmb2xsb3dzOgoK ICAgICAgIFVuZGVyICJCb3JkZXIgR2F0ZXdheSBQcm90b2NvbCAoQkdQKSBQYXJhbWV0ZXJzIjoK ICAgICAgIFJlZ2lzdHJ5OiAiQkdQIFJvdXRlIFJlZnJlc2ggU3ViY29kZXMiCiAgICAgICBSZWZl cmVuY2U6IFtkcmFmdC1pZXRmLWlkci1iZ3AtZW5oYW5jZWQtcmVmcmVzaC0wNi50eHRdCiAgICAg ICBSZWdpc3RyYXRpb24gUHJvY2VkdXJlKHMpOiBWYWx1ZXMgMC0xMjcgU3RhbmRhcmRzIEFjdGlv biwgdmFsdWVzCiAgICAgICAxMjgtMjU0IEZpcnN0IENvbWUsIEZpcnN0IFNlcnZlZCwgVmFsdWUg MjU1IHJlc2VydmVkCgogICAgICAgVmFsdWUgIENvZGUgICAgICAgICAgICAgICAgUmVmZXJlbmNl CiAgICAgICAwICAgICAgUm91dGUtUmVmcmVzaCAgICAgICBbUkZDMjkxOF0sIFtSRkM1MjkxXQog ICAgICAgMSAgICAgIEJvUlIgICAgICAgICAgICAgICAgW2RyYWZ0LWlldGYtaWRyLWJncC1lbmhh bmNlZC1yZWZyZXNoLTA2LnR4dF0KICAgICAgIDIgICAgICBFb1JSICAgICAgICAgICAgICAgIFtk cmFmdC1pZXRmLWlkci1iZ3AtZW5oYW5jZWQtcmVmcmVzaC0wNi50eHRdCiAgICAgICAyNTUgICAg UmVzZXJ2ZWQKCiAgIEluIGFkZGl0aW9uLCB0aGlzIGRvY3VtZW50IGRlZmluZXMgYW4gTk9USUZJ Q0FUSU9OIGVycm9yIGNvZGUgYW5kCiAgIHNldmVyYWwgZXJyb3Igc3ViY29kZXMgZm9yIHRoZSBS T1VURS1SRUZSRVNIIG1lc3NhZ2UuICBUaGUKICAgTk9USUZJQ0FUSU9OIGVycm9yIGNvZGUgbmVl ZCB0byBiZSByZWdpc3RlcmVkIHdpdGggdGhlIElBTkEuICBXZQogICByZXF1ZXN0IElBTkEgdG8g Y3JlYXRlIGEgbmV3IHJlZ2lzdHJ5IGZvciB0aGUgZXJyb3Igc3ViY29kZXMgYXMKICAgZm9sbG93 czoKCgoKCgoKCgoKCgpQYXRlbCwgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMywg MjAxNCAgICAgICAgICAgICAgICAgW1BhZ2UgNV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMTQKCgogICAgICAg VW5kZXIgIkJHUCBFcnJvciBTdWJjb2RlcyI6CiAgICAgICBSZWdpc3RyeTogIkJHUCBST1VURS1S RUZSRVNIIE1lc3NhZ2UgRXJyb3Igc3ViY29kZXMiCiAgICAgICBSZWZlcmVuY2U6IFtkcmFmdC1p ZXRmLWlkci1iZ3AtZW5oYW5jZWQtcmVmcmVzaC0wNi50eHRdCiAgICAgICBSZWdpc3RyYXRpb24g UHJvY2VkdXJlKHMpOiBWYWx1ZXMgMC0xMjcgU3RhbmRhcmRzIEFjdGlvbiwgdmFsdWVzCiAgICAg ICAxMjgtMjU1IEZpcnN0IENvbWUsIEZpcnN0IFNlcnZlZAoKICAgICAgIFZhbHVlICBDb2RlICAg ICAgICAgICAgICAgICAgICAgUmVmZXJlbmNlCiAgICAgICAwICAgICAgUmVzZXJ2ZWQKICAgICAg IDEgICAgICBJbnZhbGlkIE1lc3NhZ2UgTGVuZ3RoICAgW2RyYWZ0LWlldGYtaWRyLWJncC1lbmhh bmNlZC1yZWZyZXNoLTA2LnR4dF0KCjcuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucwoKICAgVGhp cyBleHRlbnNpb24gdG8gQkdQIGRvZXMgbm90IGNoYW5nZSB0aGUgdW5kZXJseWluZyBzZWN1cml0 eSBpc3N1ZXMuCgo4LiAgQWNrbm93bGVkZ2VtZW50cwoKICAgVGhlIGF1dGhvcnMgd291bGQgbGlr ZSB0byB0aGFuayBQZWRybyBNYXJxdWVzLCBQcmFkb3NoIE1vaGFwYXRyYSwKICAgUm9iZXJ0IFJh c3p1aywgUHJhbmF2IE1laHRhLCBTaHlhbSBTZXRodXJhbSwgQnJ1bm8gRGVjcmFlbmUsIE1hcnRp bgogICBEamVybmFlcywgSmVmZiBIYWFzLCBJbHlhIFZhcmxhc2hraW4sIFJvYiBTaGFraXIsIFBh dWwgSmFrbWEsIEppZQogICBEb25nLCBRaW5nIFplbmcsIEFsYmVydCBUaWFuLCBKYWtvYiBIZWl0 eiBhbmQgQ2hyaXMgSGFsbCBmb3IgdGhlaXIKICAgcmV2aWV3IGFuZCBjb21tZW50cy4gIFRoZSBh dXRob3JzIHdvdWxkIGxpa2UgdG8gdGhhbmsgSm9obiBTY3VkZGVyCiAgIGZvciB0aGUgcmV2aWV3 IGFuZCBjb250cmlidXRpb24gdG8gdGhpcyBkb2N1bWVudC4KCjkuICBOb3JtYXRpdmUgUmVmZXJl bmNlcwoKICAgW1JGQzIxMTldICBCcmFkbmVyLCBTLiwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJG Q3MgdG8gSW5kaWNhdGUKICAgICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQs IFJGQyAyMTE5LCBNYXJjaCAxOTk3LgoKICAgW1JGQzI5MThdICBDaGVuLCBFLiwgIlJvdXRlIFJl ZnJlc2ggQ2FwYWJpbGl0eSBmb3IgQkdQLTQiLCBSRkMgMjkxOCwKICAgICAgICAgICAgICBTZXB0 ZW1iZXIgMjAwMC4KCiAgIFtSRkM0MjcxXSAgUmVraHRlciwgWS4sIExpLCBULiwgYW5kIFMuIEhh cmVzLCAiQSBCb3JkZXIgR2F0ZXdheQogICAgICAgICAgICAgIFByb3RvY29sIDQgKEJHUC00KSIs IFJGQyA0MjcxLCBKYW51YXJ5IDIwMDYuCgogICBbUkZDNDcyNF0gIFNhbmdsaSwgUy4sIENoZW4s IEUuLCBGZXJuYW5kbywgUi4sIFNjdWRkZXIsIEouLCBhbmQgWS4KICAgICAgICAgICAgICBSZWto dGVyLCAiR3JhY2VmdWwgUmVzdGFydCBNZWNoYW5pc20gZm9yIEJHUCIsIFJGQyA0NzI0LAogICAg ICAgICAgICAgIEphbnVhcnkgMjAwNy4KCiAgIFtSRkM1MjkxXSAgQ2hlbiwgRS4gYW5kIFkuIFJl a2h0ZXIsICJPdXRib3VuZCBSb3V0ZSBGaWx0ZXJpbmcKICAgICAgICAgICAgICBDYXBhYmlsaXR5 IGZvciBCR1AtNCIsIFJGQyA1MjkxLCBBdWd1c3QgMjAwOC4KCiAgIFtSRkM1NDkyXSAgU2N1ZGRl ciwgSi4gYW5kIFIuIENoYW5kcmEsICJDYXBhYmlsaXRpZXMgQWR2ZXJ0aXNlbWVudAogICAgICAg ICAgICAgIHdpdGggQkdQLTQiLCBSRkMgNTQ5MiwgRmVicnVhcnkgMjAwOS4KCgoKCgoKCgpQYXRl bCwgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMywgMjAxNCAgICAgICAgICAgICAg ICAgW1BhZ2UgNl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMTQKCgpBdXRob3JzJyBBZGRyZXNzZXMKCiAgIEtl eXVyIFBhdGVsCiAgIENpc2NvIFN5c3RlbXMKICAgMTcwIFcuIFRhc21hbiBEcml2ZQogICBTYW4g Sm9zZSwgQ0EgOTUxMjQgIDk1MTM0CiAgIFVTQQoKICAgRW1haWw6IGtleXVwYXRlQGNpc2NvLmNv bQoKCiAgIEVua2UgQ2hlbgogICBDaXNjbyBTeXN0ZW1zCiAgIDE3MCBXLiBUYXNtYW4gRHJpdmUK ICAgU2FuIEpvc2UsIENBIDk1MTI0ICA5NTEzNAogICBVU0EKCiAgIEVtYWlsOiBlbmtlY2hlbkBj aXNjby5jb20KCgogICBCYWxhamkgVmVua2F0YWNoYWxhcGF0aHkKCiAgIEVtYWlsOiBiYWxhamlf cHZAaG90bWFpbC5jb20KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKClBhdGVsLCBldCBhbC4g ICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAzLCAyMDE0ICAgICAgICAgICAgICAgICBbUGFnZSA3 XQo= --_004_CF0FD8F86170Bkeyupateciscocom_-- From shares@ndzh.com Thu Jan 30 10:23:21 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE8E1A0072 for ; Thu, 30 Jan 2014 10:23:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpOMVi0Pwi7q for ; Thu, 30 Jan 2014 10:23:19 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 95E151A0054 for ; Thu, 30 Jan 2014 10:23:19 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Keyur Patel \(keyupate\)'" , References: In-Reply-To: Date: Thu, 30 Jan 2014 13:23:07 -0500 Message-ID: <007701cf1de8$53571d70$fa055850$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0078_01CF1DBE.6A83FBA0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIGxPj1Dal1f7T6ogADUl2weXy9ppouRkJA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 18:23:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0078_01CF1DBE.6A83FBA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit IDR WG: We will have a 1 week WG LC on this version of the draft-ietf-idr-bgp-enhanced-route-refresh-06.txt Please comment. It would help if you would indicate: support/no-support in your discussion. Thank you, Sue and John From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] Sent: Thursday, January 30, 2014 1:20 PM To: idr@ietf.org Cc: Susan Hares; John G. Scudder Subject: draft-ietf-idr-bgp-enhanced-route-refresh-06.txt Folks, Thank you all for detailed review of the document during the last call. I have revised the draft as per the following WG Last call comments: - Clarified GR/EOR interaction with Enhanced Route Refresh. - Clarified the Error Handling text for Enhanced Route Refresh with Invalid message subtypes. - Updated Author's information and Acknowledgement section. Best Regards, Keyur ------=_NextPart_000_0078_01CF1DBE.6A83FBA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IDR WG:

 

We will have a 1 week WG LC on this version of the = draft-ietf-idr-bgp-enhanced-route-refresh-06.txt =

Please comment.  It would help if you would indicate: = support/no-support in your discussion.

 

Thank you,

Sue and John

 

 

From:= = Keyur Patel (keyupate) [mailto:keyupate@cisco.com]
Sent: = Thursday, January 30, 2014 1:20 PM
To: = idr@ietf.org
Cc: Susan Hares; John G. = Scudder
Subject: = draft-ietf-idr-bgp-enhanced-route-refresh-06.txt

 

Folks,

 

Thank you all for detailed review of the document during the last call. = I have revised the draft as per the following WG Last call = comments:

 

 

-  Clarified GR/EOR interaction with Enhanced Route = Refresh.

 

-  Clarified the Error Handling text for Enhanced Route Refresh = with Invalid message subtypes.

 

-  Updated Author's information and Acknowledgement = section.

 

 

 

Best Regards,

Keyur

 

------=_NextPart_000_0078_01CF1DBE.6A83FBA0-- From thomas.mangin@exa-networks.co.uk Thu Jan 30 10:27:48 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CCE41A0054; Thu, 30 Jan 2014 10:27:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zGpV9t7pCD2; Thu, 30 Jan 2014 10:27:46 -0800 (PST) Received: from out-7.mail.exa.net.uk (out-7.mail.exa.net.uk [82.219.4.135]) by ietfa.amsl.com (Postfix) with ESMTP id E27431A04CC; Thu, 30 Jan 2014 10:27:40 -0800 (PST) Received: from smtp-3.mail.exa.net.uk (smtp-3.mail.exa.net.uk [82.219.5.3]) by out-7.mail.exa.net.uk (ExaSMTPD) with ESMTP id 4FEB5A0056; Thu, 30 Jan 2014 18:27:36 +0000 (GMT) Received: from [192.168.1.10] (ptr-1.212.219.82.rev.exa.net.uk [82.219.212.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: thomas@mangin.com) by smtp-3.mail.exa.net.uk (ExaSMTPD) with ESMTPSA id B7CD96C0047; Thu, 30 Jan 2014 18:27:35 +0000 (GMT) Content-Type: multipart/signed; boundary="Apple-Mail=_3FF2E58E-AC1A-4B2B-87E7-238518CA457D"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Mangin In-Reply-To: Date: Thu, 30 Jan 2014 18:27:34 +0000 Message-Id: <2FB660E9-6E1F-4FA5-8B20-E7826542560E@exa-networks.co.uk> References: <5EECE2EC-9406-4BDB-8AEB-ADD1B7ABB167@ericsson.com> To: idr-bounces@ietf.org X-Mailer: Apple Mail (2.1827) X-Virus-Scanned: clamav-milter 0.97.8 at out-2-2.mail.exa.net.uk X-Virus-Status: Clean Cc: "Keyur Patel \(keyupate\)" , "bruno.decraene@orange.com" , "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 18:27:48 -0000 --Apple-Mail=_3FF2E58E-AC1A-4B2B-87E7-238518CA457D Content-Type: multipart/alternative; boundary="Apple-Mail=_B38AAB9D-865D-4FDD-97A2-287A6C6CAAA7" --Apple-Mail=_B38AAB9D-865D-4FDD-97A2-287A6C6CAAA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 30 Jan 2014, at 18:05, Robert Raszuk wrote: > Maybe this questions comes late considering deployed implementations, = but I guess it is better late then never :)=20 Can someone tell us how the current implementation deal with with the = scenario discussed ? ExaBGP will honour the RR request once the initial table dump / GR is = done and the EoR was sent. It delays the reply until that point then = send the BoRR / updates / EoRR. If multiple RR for the same family or not are received, the successive = RR are ignored, until the RIB transfer is completed When sending a RR, as the RIB implementation is left to the user and no = reference RIB code exists today, the problem to deal with the incoming = B/EoRR is left to the RIB implementation. Thomas --Apple-Mail=_B38AAB9D-865D-4FDD-97A2-287A6C6CAAA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On 30 Jan 2014, at 18:05, Robert = Raszuk <robert@raszuk.net> = wrote:

Maybe this questions comes late = considering deployed implementations, but I guess it is better late then = never :) 

Can someone tell us how = the current implementation deal with with the scenario discussed = ?

ExaBGP will honour the RR request once the = initial table dump / GR is done and the EoR was sent. It delays the = reply until that point then send the BoRR / updates / EoRR.
If = multiple RR for the same family or not are received, the successive RR = are ignored, until the RIB transfer is = completed

When sending a RR, as the RIB = implementation is left to the user and no reference RIB code exists = today, the problem to deal with the incoming B/EoRR is left to the RIB = implementation.

Thomas

= --Apple-Mail=_B38AAB9D-865D-4FDD-97A2-287A6C6CAAA7-- --Apple-Mail=_3FF2E58E-AC1A-4B2B-87E7-238518CA457D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlLqmZYACgkQA/52wvuLgaEQ2wCg6ZA+RMMyyIx/mtlssDlV29iV 9dMAniD+JVR4Ynme/w+hBDiY1GIsiNF+ =2sy7 -----END PGP SIGNATURE----- --Apple-Mail=_3FF2E58E-AC1A-4B2B-87E7-238518CA457D-- From bruno.decraene@orange.com Fri Jan 31 00:35:18 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 593DB1A0570 for ; Fri, 31 Jan 2014 00:35:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ccv0HmBU3zLO for ; Fri, 31 Jan 2014 00:35:08 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCBD1A0574 for ; Fri, 31 Jan 2014 00:35:07 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id DF97F324489; Fri, 31 Jan 2014 09:35:02 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id BCA2C35C045; Fri, 31 Jan 2014 09:35:02 +0100 (CET) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Fri, 31 Jan 2014 09:35:02 +0100 From: To: "Keyur Patel (keyupate)" , Jakob Heitz Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHPHeIf3MXmo8KxoESEhujQiGLM/Zqederg Date: Fri, 31 Jan 2014 08:35:01 +0000 Message-ID: <3487_1391157302_52EB6036_3487_5085_1_53C29892C857584299CBF5D05346208A070E085A@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <5EECE2EC-9406-4BDB-8AEB-ADD1B7ABB167@ericsson.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A070E085APEXCVZYM11corpo_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.31.25115 Cc: "idr@ietf.org" Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 08:35:18 -0000 --_000_53C29892C857584299CBF5D05346208A070E085APEXCVZYM11corpo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Keyur, Jakob, Chris, Thanks for the clarification. I had missed the sentence stating that BoRR c= an be sent _any_ time. (so including multiple consecutive ones) Please disregard my last comments. Bruno From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] Sent: Thursday, January 30, 2014 6:39 PM To: Jakob Heitz; DECRAENE Bruno IMT/OLN Cc: idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Bruno, Agree with Jakob here. :) The Route Refresh could restart for various reaso= ns (and depending on implementations). In that scenario, it could simply re= send a BoRR again. The receiver side behavior doesn't change in such a case= . Upon a receipt of BoRR mark the routes stale and restart the timer. Having said that implementations could log the receipt of such back-to-back= BoRRs or EoRRs for further analysis. But it doesn't look like a Bug. Regards, Keyur From: Jakob Heitz > Date: Thu, 30 Jan 2014 17:26:12 +0000 To: "bruno.decraene@orange.com" > Cc: Keyur Patel >, "idr@ietf.= org" > Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Then make it not a bug. A second BoRR means the first one was aborted. The draft as it stands alrea= dy covers this case. -- Jakob Heitz. On Jan 30, 2014, at 8:43 AM, "bruno.decraene@orange.com" > wrote: Hi Keyur, Comments inlined #Bruno From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] Sent: Thursday, January 30, 2014 3:48 PM To: DECRAENE Bruno IMT/OLN Cc: idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Bruno, Comments Inlined #Keyur. From:> Date: Thu, 30 Jan 2014 10:27:56 +0000 To: Keyur Patel > Cc: "idr@ietf.org" > Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Keyur, Thanks for your reply. Your proposed new text, using NOTIFICATION only for syntax errors seems muc= h better to me. Thanks for the clarification. Ideally, in addition, I would prefer to have a text also covering other typ= es of errors. At least the violation of explicit statement in the draft. E.= g. for the following 2 MUST " Before the speaker starts a route refresh that is either initiated locally, or in response to a "normal route refresh request" from the peer, the speaker MUST send a BoRR message. After the speaker completes the re-advertisement of the entire Adj-RIB-Out to the peer, it MUST send an EoRR message." Regarding the first one, IMHO there is no harm if the MUST is not enforced.= One option may be :s/MUST/SHOULD; or a statement in =A7 "Error handling" o= n how to handle this error (e.g. log and nothing else). Regarding the second one, I'd like to see a text specifying what should be = done when I receive two BoRR. E.g. -a- consider that the second BoRR should be considered as a EoRR+ BoRR -b- ignore/abort the first EoRR procedure (i.e. remark all routes as STALE = when the second EoRR is received) -c- ignore the second EoRR. #Keyur: If the sender has sent two BoRRs (without an EoRR) then it means it= has aborted the first route refresh table announcement and restarted the r= oute refresh table announcement. The second EoRR will be essentially no-op = (I.e C case). Implementations can log the no-op behavior. #Bruno : well we don't really know what it means for the sender because it = was not supposed to do this in the first place, so it's a bug. Ok for your proposition to ignore the second EoRR. Would it be possible to = add this sentence/point in the =A7 "Error handling?" Especially since this = seems to contradict the spec which seems more on the side of "b": "When a BGP speaker receives a BoRR message from a peer, it MUST mark all the routes with the given from that peer as stale." Thanks, Regards, Bruno Regards, Keyur (plus obviously log the error in all cases) "a" sounds dangerous to me. "b" should a priori ok (accept a small error but consider that the speaker = remember (and acted as per) its latest message.) "c" is the safest path (there is a error, I don't know what it is so I take= the safest option) Considering the motivation for this draft (enhance BGP robustness, but not = bring a new feature), I think I would prefer "c" which is the more robust. = Especially given that if the receiver has a doubt, I has a way to clear it = by sending a new Route Refresh message. But I guess I would be fine with "b" if you/the WG have a different opinion. (My understanding of the current draft, is that "b" is expected, but in all= cases I would prefer a specific text in =A7 "Error handling") Thanks, Cheers, Bruno From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] Sent: Wednesday, January 29, 2014 11:16 PM To: DECRAENE Bruno IMT/OLN; Robert Raszuk Cc: idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Bruno, We only generate Notification for invalid length. Apologies for the confusi= on. Attached is the revised text. Regards, Keyur The error handling specified in this section is applicable only when a BGP speaker has received the "Enhanced Route Refresh Capability" from a peer. If the length, excluding the fixed-size message header, of the received ROUTE-REFRESH message with Message Subtype 1 and 2 is not 4, then the BGP speaker MUST send a NOTIFICATION message with the Error Code of "ROUTE-REFRESH Message Error" and the subcode of "Invalid Message Length". The Data field of the NOTIFICATION message MUST contain the complete ROUTE-REFRESH message. When the BGP speaker receives a ROUTE-REFRESH message with a "Message Subtype" field other than 1 or 2, it MUST ignore the received ROUTE- REFRESH message. It SHOULD log an error for further analysis. From: > Date: Wed, 29 Jan 2014 09:51:00 +0000 To: Robert Raszuk >, Keyur Pate= l > Cc: "idr@ietf.org" > Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi all, From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: Wednesday, January 29, 2014 10:15 AM To: Dongjie (Jimmy) Cc: Keyur Patel (keyupate); idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Jimmy and all, I think Enke and Keyur's proposed text with help from Jakob makes the behav= ior simplified and deterministic to hold on BoRR till first EoR is seen. IMHO it should be also spelled out what is the expected sequence error hand= ling here [Bruno] +1. And taking into account possible interaction with draft-ietf-i= dr-bgp-gr-notification BTW: "When the BGP speaker detects an error while processing a ROUTE-REFRESH mes= sage with a non-zero "Message Subtype" field, it MUST send a NOTIFICATION m= essage with Error Code "ROUTE-REFRESH Message Error"." Seems a priori not inline with the recommendation from draft-ietf-grow-ops-= reqs-for-bgp-error-handling (which is to limit the consequences of error ha= ndling). Are we sure that no error condition could be handled in a more fri= endly way? (e.g. if BoRR is not sent following a "normal route refresh requ= est" or if 2 BoRR are sent consecutively...) Thanks, Regards, Bruno ... I think not following "MUST NOT" shall implicitly result in entire sess= ion drop and complete restart ? Any error code ? Best, R. On Wed, Jan 29, 2014 at 9:22 AM, Dongjie (Jimmy) > wrote: Hi Robert, Agree that in these cases the RRQ cannot be ignored, so postpone may be a b= etter choice. While IMO stop the initial update and start over may delay the initial conv= ergence, and as you said it also relates to update group processing. What = do you think about the new text provided by Keyur? Best regards, Jie From:rraszuk@gmail.com [mailto:rraszuk@gmail.com<= mailto:rraszuk@gmail.com>] On Behalf Of Robert Raszuk Sent: Sunday, January 26, 2014 11:03 PM To: Dongjie (Jimmy) Cc: Keyur Patel (keyupate); Jakob Heitz; idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Hi Jie, I think it actually very easy to say that initial update can not ever guara= ntee that RRQ received during its sending may meet the peer's need. Example 1: SAFI 128 - During receiving initial update from RR to PE new VRF got added = with new RT import. Unfortunately those updates received within initial upd= ate were already dropped as not interesting by the PE. RR must resend full = table after completed initial update. (Of course this is the case where the= re is no RTC and that's why RTC helps a lot here by incremental nature). Example 2: SAFI 1 - Operator has modified inbound policy on EBGP peer during processin= g of incoming updates and those originally were dropped. No soft reconfig i= n set. Conclusion: RRQ can not ever be ignored. Sure they can be delayed or batched (case of m= ultiple peers within the same update/peer group) sending near RRQs (cluster= of PEs got provisioned from central management station). But as Keyur alre= ady mentioned those are rather standard local implementation optimizations. Question: Does it maybe make sense to stop initial update when receiving RRQ from a p= eer and start over ? Of course if peer is part of large update group it wou= ld have to be removed dynamically from it so other members are not delayed.= In any case I think this does not impact the spec but the implementation. Cheers, R. On Sun, Jan 26, 2014 at 7:13 PM, Dongjie (Jimmy) > wrote: Hi Keyur, Jakob, Agree that "postpone" may be better. The point is we could avoid the compli= cated cases/considerations of performing route refresh during initial updat= e:) For "ignore", I was thinking of scenarios in which the route refresh requir= ement may already be met by the initial update, while I'd admit it is hard = to say... Best regards, Jie -----Original Message----- From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] Sent: Sunday, January 26, 2014 8:30 PM To: Jakob Heitz; Dongjie (Jimmy) Cc: idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh Jie, I agree with Jakob. You could make it *an implementation behavior* to postp= one the route refresh reply. Regards, Keyur On 1/26/14 1:29 AM, "Jakob Heitz" > wrote: >You can definitely not ignore it, but you could postpone it. > >-- >Jakob Heitz. > >> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" > >>wrote: >> >> After reading the analyses in this thread, my personal feeling is >>maybe we should avoid the interleaving between GR initial update and >>route refresh/enhanced route refresh, since the initial update is just >>sending the whole Adj-RIB-Out, there is no obvious advantage to start >>a route refresh/enhance route refresh during it. So a speaker should >>ignore the RRQ received during the initial update. Thoughts? >> >> Best regards, >> Jie >> >> -----Original Message----- >> From: Idr [mailto:idr-bounces@ietf.org] On = Behalf Of Jakob Heitz >> Sent: Saturday, January 25, 2014 10:48 PM >> To: Chris Hall; idr@ietf.org >> Subject: Re: [Idr] WG LC for >> draft-ietf-idr-bgp-enhanced-route-refresh >> >> RFCs are written for coders "practiced" in the art". >> If anyone sends an EoRR before the adj-RIB-out is fully populated, >>then it's a BUG. >> This does not need to be said. >> >> Personally, I believe a route refresh request should not be honored >>until GR is complete. >> Also, I don't believe a timer for the receipt of EoRR is necessary, >>because the EoRR is guaranteed. >> Guaranteed means "unless the session drops first". >> -- >> >> Jakob Heitz. >> >> ________________________________________ >> From: Chris Hall [chris.hall@highwayman.com] >> Sent: Saturday, 25 January 2014 11:27 AM >> To: idr@ietf.org >> Cc: Jakob Heitz >> Subject: RE: [Idr] WG LC for >> draft-ietf-idr-bgp-enhanced-route-refresh >> >> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37): >> ... >>> Silence means don't do it. >> >> Hmmm.... as a principle I'm more comfortable with "that which isn't >>prohibited is permitted".... >> >>> You would definitely NOT want BoRR to flush old stales. >> >> ....but, given the definite requirement, and given that the current >>precedent for "marking stale" does flush old stale, then a few words >>for the avoidance of doubt ? >> >>> Restarting the timer might be a good idea. >> >> I dunno... a route which remains stale for "a long time" is, of >>course, a candidate for being withdrawn: so having started a timer the >>first time things are set stale, I would avoid extending that -- at >>least for Graceful Restart, where the whole withdraw thing has been "on-h= old" >>since the last session failed. For route-refresh I guess there's more >>of a presumption that stale routes will be refreshed sooner or later, >>and in the meantime they remain good. So if the route-refresh is >>(repeatedly) restarted for some reason, perhaps it is more reasonable >>to extend the flush deadline -- but avoid doing this indefinitely ? >> >> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I have >>built in Quagga prioritise route changes (pending changes and any that >>occur during the refresh) over refresh updates. This makes it more >>likely that remaining stale routes are still good. But the other end >>cannot know that. >> >> The paragraph in the draft discussing the "entire Adj-RIB-Out" >>defines that to be the entries present "at the start of the route >>refresh operation", and observes that these comprise both reachable >>and unreachable routes. [An "of" after "comprise" sets teeth on edge, >>BTW.] I'm really not sure what this paragraph is trying to tell me. >> The reference to unreachable routes appears to suggest that pending >>withdraws should be sent as part of the refresh -- so not left to the >>EoRR to implement at the end. The point at which the EoRR is sent is >>defined such that it excludes any Adj-RIB-Out entries added after the >>route-refresh started, but includes any which are changed during the >>process. It seems reasonable to delay any brand new reachable >>prefixes until after all previously announced ones have been refreshed >>and the EoRR sent -- if that's the intent here. Changes which occur >>before the refresh gets to a given entry are pretty naturally swept up >>by the refresh. Changes which occur after the refresh has gone past, >>could/should be deferred to after the EoRR ? Does it make a >>difference if the change is a withdraw ? (Of course MRAI may kick in her= e. Ah. >>MRAI and route-refresh, there's a topic !) >> >> I think the essence of the rule is that the EoRR should be sent once >>all prefixes previously advertised to the peer as reachable have been >>refreshed, ie announced or withdrawn (at least) once. Or, perhaps >>more strictly, not *before* those prefixes have *all* been announced >>once -- given that the EoRR will promptly bang un-advertised stuff on the= head. >>Even more strictly perhaps: not send EoRR *before* any withdraws >>implied by it are required or desirable. >> >> Depending on the implementation, a given sender may or may not be >>able to determine the minimum set of updates required before sending EoRR. >> >> If the refresh operation takes a long time, there may be good >>routeing reasons to arrange for some route changes to be sent to the peer= "early" >>-- that is to send announcements which do not contribute to the >>refresh, but which are important enough to warrant delaying the end of >>the refresh. That could be a matter for recommendation(s) in the standar= d. >> >> NB: given that the timing of the EoRR is tied to the state of the >>Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. At >>the beginning of the initial update, the Restarting and Receiving >>speakers have: >> >> Restarting: Empty Adj-RIB-In Empty Adj-RIB-Out >> >> Receiving: Empty Adj-RIB-Out Stale Adj-RIB-In >> >> Now suppose (bonkers or otherwise) the receiving speaker sends an RRQ >>part way through the initial update. The restarting speaker responds >>with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specification. >> The receiving speaker sees the EoRR, and flushes stale. >>Unfortunately, if the restarting speaker has not yet fully populated >>its Adj-RIB-Out, then many further routes will be sent before the EoR >>falls due -- but the receiving speaker has already flushed their tiny >>posteriors :-( >> >> I am coming to the view that route-refresh during a Graceful Restart >>initial update is a horse of a different colour altogether. >> >> [So the assumption that EoRR and EoR are triggered by the same thing >>was completely wrong, and I apologise for it.] >> >> Chris >> >> _______________________________________________ >> 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 ___________________________________________________________________________= ______________________________________________ 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, 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 authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ 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, 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 authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ 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, 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 authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ 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, 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 authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A070E085APEXCVZYM11corpo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

= Hi Keyur, Jakob, Chris,=

=  

= Thanks for the clarification. I h= ad missed the sentence stating that BoRR can be sent _any_ time. (so including multiple consecutive ones)

= Please disregard my last comments= .

=  

= Bruno

=  

From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com]
Sent: Thursday, January 30, = 2014 6:39 PM
To: Jakob Heitz; DECRAENE Br= uno IMT/OLN
Cc: idr@ietf.org
Subject: Re: [Idr] WG LC for= draft-ietf-idr-bgp-enhanced-route-refresh

 

Hi Bruno,

 

Agree with Jakob here. :) The Route Refresh cou= ld restart for various reasons (and depending on implementations). In that scenario, it could simply resend a BoRR again. The receiver side b= ehavior doesn't change in such a case. Upon a receipt of BoRR mark the rout= es stale and restart the timer.

 

Having said that implementations could log the recei= pt of such back-to-back BoRRs or EoRRs for further analysis. But it doesn't look like a Bug.

 

Regards,

Keyur

 

From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Thu, 30 Jan 2014 17:26= :12 +0000
To: "bruno.decraene@orange.com" <bruno.decraene@orange.com>
Cc: Keyur Patel <keyupate@cisco.com>, "idr@ietf.org" <idr@ietf.org>
Subject: Re: [Idr] WG LC for= draft-ietf-idr-bgp-enhanced-route-refresh

 

Then make it not a bug.

A second BoRR means the first one was aborted. The d= raft as it stands already covers this case.

--

Jakob Heitz.

 


On Jan 30, 2014, at 8:43 AM, "bruno.decraene@orange.com" <bruno.decraene@orange.com> wrote:

= Hi Keyur,

=  

= Comments inlined #Bruno

=  

= From: Keyur Patel (keyupate) [mailto:keyup= ate@cisco.com]
Sent: Thursday, January 30, = 2014 3:48 PM
To: DECRAENE Bruno IMT/OLN Cc: idr@ietf.org
Subject: Re: [Idr] WG LC for= draft-ietf-idr-bgp-enhanced-route-refresh

 =

Hi Bruno,

 

Comments Inlined #Keyur.

 

From:<bruno.decraene@orange.com> Date: Thu, 30 Jan 2014 10:27= :56 +0000
To: Keyur Patel <keyupate@cisco.com>
Cc: "idr@ietf.org" <id= r@ietf.org>
Subject: RE: [Idr] WG LC for= draft-ietf-idr-bgp-enhanced-route-refresh

 

= Hi Keyur,

=  

= Thanks for your reply.

= Your proposed new text, using NOT= IFICATION only for syntax errors seems much better to me. Thanks for the clarification.

=  

= Ideally, in addition, I would pre= fer to have a text also covering other types of errors. At least the violation of explicit statement in the draft. E.g. for the following 2= MUST<= /o:p>

“   Before the speaker starts a rout= e refresh that is either initiated

   locally, or in response to a "norm= al route refresh request" from the=

   peer, the speaker MUST send a B= oRR message.  After the speaker

   completes the re-advertisement of the e= ntire Adj-RIB-Out to the peer,

   it MUST send an = EoRR message.”

=  

= Regarding the first one, IMHO the= re is no harm if the MUST is not enforced. One option may be :s/MUST/SHOULD; or a statement in =A7 “Error handling” on how to handle this e= rror (e.g. log and nothing else).

= Regarding the second one, I’= ;d like to see a text specifying what should be done when I receive two BoRR. E.g.=

= -a- consider that the second BoRR= should be considered as a EoRR+ BoRR

= -b- ignore/abort the first EoRR p= rocedure (i.e. remark all routes as STALE when the second EoRR is received)<= o:p>

= -c- ignore the second EoRR.

=  

#Keyur: If the sender has sent two Bo= RRs (without an EoRR) then it means it has aborted the first route refresh table announcement and restarted the route refresh table announcem= ent. The second EoRR will be essentially no-op (I.e C case). Implementations can log the no-op behavior.

= #Bruno : well we don’t= really know what it means for the sender because it was not supposed to do this in the first place, so it’s a bug.

Ok for your proposition to ignore the second EoRR. =
Would it be possible to add this sentence/point in the =A7 “Error han=
dling?” Especially since this seems to contradict the spec  whic=
h seems more on the side of “b”: “When

   a BGP speaker receives a BoRR message f= rom a peer, it MUST mark all

   the routes with the given <AFI, SAFI= > from that peer as stale.”

= Thanks,

= Regards,

= Bruno 

 

Regards,

Keyur

 

= (plus obviously log the error in = all cases)<= o:p>

=  

= “a” sounds dangerous = to me.=

= “b” should a priori o= k (accept a small error but consider that the speaker remember (and acted as per) its latest message.)

= “c” is the safest pat= h (there is a error, I don’t know what it is so I take the safest opt= ion)

=  

= Considering the motivation for th= is draft (enhance BGP robustness, but not bring a new feature), I think I would prefer “c” which is the more robust. Especiall= y given that if the receiver has a doubt, I has a way to clear it by sendin= g a new Route Refresh message.

= But I guess I would be fine with = “b” if you/the WG have a different opinion.

= (My understanding of the current = draft, is that “b” is expected, but in all cases I would prefer a specific text in  =A7 “Error handling”)

=  

= Thanks,

= Cheers,

= Bruno

=  

=  

= From: Keyur Patel (keyupate) [mailto:keyup= ate@cisco.com]
Sent: Wednesday, January 29,= 2014 11:16 PM
To: DECRAENE Bruno IMT/OLN; = Robert Raszuk
Cc: idr@ietf.org
Subject: Re: [Idr] WG LC for= draft-ietf-idr-bgp-enhanced-route-refresh

 =

Hi Bruno,

 

We only generate Notification for invalid length. Ap= ologies for the confusion. Attached is the revised text.

 

Regards,

Keyur

 

<snip>

The error handling specified in this section is appl= icable only when

   a BGP speaker has received the "En= hanced Route Refresh Capability"

   from a peer.

 

   If the length, excluding the fixed-size= message header, of the

   received ROUTE-REFRESH message with Mes= sage Subtype 1 and 2 is not 4,

   then the BGP speaker MUST send a NOTIFI= CATION message with the Error

   Code of "ROUTE-REFRESH Message Err= or" and the subcode of "Invalid

   Message Length".  The Data fi= eld of the NOTIFICATION message MUST

   contain the complete ROUTE-REFRESH mess= age.

 

   When the BGP speaker receives a ROUTE-R= EFRESH message with a "Message

   Subtype" field other than 1 or 2, = it MUST ignore the received ROUTE-

   REFRESH message.  It SHOULD log an= error for further analysis.

 

<snip>

 

From: <bruno.de= craene@orange.com>
Date: Wed, 29 Jan 2014 09:51= :00 +0000
To: Robert Raszuk <robert@raszuk.net>, Keyur Patel <<= a href=3D"mailto:keyupate@cisco.com">keyupate@cisco.com>
Cc: "idr@ietf.org" <id= r@ietf.org>
Subject: RE: [Idr] WG LC for= draft-ietf-idr-bgp-enhanced-route-refresh

 

= Hi all,

=  

=  

 

Hi Jimmy and all,

 

I think Enke and Keyur's proposed text with help from Jakob makes t= he behavior simplified and deterministic to hold on BoRR till first EoR is seen.

 

IMHO it should be also spelled out what is the expected sequence er= ror handling here =

=  

= [Bruno] +1.  And taking = into account possible interaction with draft-ietf-idr-bgp-gr-notification

=  

= BTW:

= “When the BGP speaker detec= ts an error while processing a ROUTE-REFRESH message with a non-zero "= Message Subtype" field, it MUST send a NOTIFICATION message with Error Code &= quot;ROUTE-REFRESH Message Error".”

=  

= Seems a priori not inline with th= e recommendation from draft-ietf-grow-ops-reqs-for-bgp-error-handling (which is to limit the consequences of error handling). Are we sure that n= o error condition could be handled in a more friendly way? (e.g. if BoRR is= not sent following a “normal route refresh request” or if 2 Bo= RR are sent consecutively…)

=  

= Thanks,

= Regards,

= Bruno

=  

=  

... I think not following "M= UST NOT" shall implicitly result in entire session drop and complete r= estart ? Any error code ?

 

Best,
R.

 

 

On Wed, Jan 29, 2014 at = 9:22 AM, Dongjie (Jimmy) <jie.dong@huawei.com> wrote:

Hi Robert, =

 

Agree that in these cases the RRQ cannot be ignored, so postpone may be a better choice.

 

While IMO stop the initial update and start over may delay the initial convergence, and as you said  it als= o relates to update group processing. What do you think about the new text = provided by Keyur? =

 

Best regards,

Jie

 

From:rraszuk@gmail.com= [mailto:rraszuk@gma= il.com] On Behalf Of Robert Raszuk Sent: Sunday, January 26, 20= 14 11:03 PM
To: Dongjie (Jimmy)
Cc: Keyur Patel (keyupate); = Jakob Heitz; idr@ietf.org


Subject: Re: [Idr] WG LC for= draft-ietf-idr-bgp-enhanced-route-refresh

 

Hi Jie,

 

I think it actually very easy to say that initial update can not ever guarantee that RRQ received during its sending may mee= t the peer's need.

 

Example 1:

 

SAFI 128 - During receiving initial update from RR to PE new VRF got added with new RT import. Unfortunately those updates= received within initial update were already dropped as not interesting by = the PE. RR must resend full table after completed initial update. (Of cours= e this is the case where there is no RTC and that's why RTC helps a lot here by incremental nature). 

 

Example 2: 

 

SAFI 1 - Operator has modified inbound policy on EBGP peer during processing of incoming updates and those originally were = dropped. No soft reconfig in set. =

 

Conclusion:

 

RRQ can not ever be ignored. Sure they can be delayed or batched (case of multiple peers within the same update/peer group) send= ing near RRQs (cluster of PEs got provisioned from central management stati= on). But as Keyur already mentioned those are rather standard local impleme= ntation optimizations. 

 

Question:

 

Does it maybe make sense to stop initial update when receiving RRQ from a peer and start over ? Of course if peer is part = of large update group it would have to be removed dynamically from it so ot= her members are not delayed. In any case I think this does not impact the s= pec but the implementation.

 

Cheers,
R.

 

 

 

On Sun, Jan 26, 2014 at= 7:13 PM, Dongjie (Jimmy) <jie.dong@huawei.com> wrote:

Hi Keyur, Jakob,

Agree that "postpone" may be better. The point is we could avoid = the complicated cases/considerations of performing route refresh during ini= tial update:)

For "ignore", I was thinking of scenarios in which the route refr= esh requirement may already be met by the initial update, while I'd admit i= t is hard to say...



Best regards,
Jie

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

From: Keyur Patel (keyu= pate) [mailto:keyup= ate@cisco.com]
Sent: Sunday, January 26, 2014 8:30 PM
To: Jakob Heitz; Dongjie (Jimmy)
Cc: idr@ietf.org
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-enhanced-route-refresh

Jie,

I agree with Jakob. You could make it *an implementation behavior* to postp= one the route refresh reply.


Regards,
Keyur

On 1/26/14 1:29 AM, "Jakob Heitz" <jakob.heitz@ericsson.com> wrote:<= br>
>You can definitely not ignore it, but you could postpone it.
>
>--
>Jakob Heitz.
>
>> On Jan 26, 2014, at 12:17 AM, "Dongjie (Jimmy)" <jie.dong@huawei.com>
>>wrote:
>>
>> After reading the analyses in this thread, my personal feeling is<= br> >>maybe we should avoid the interleaving between GR initial update an= d
>>route refresh/enhanced route refresh, since the initial update is j= ust
>>sending the whole Adj-RIB-Out, there is no obvious advantage to sta= rt
>>a route refresh/enhance route refresh during it. So a speaker shoul= d
>>ignore the RRQ received during the initial update. Thoughts?
>>
>> Best regards,
>> Jie
>>
>> -----Original Message-----
>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz
>> Sent: Saturday, January 25, 2014 10:48 PM
>> To: Chris Hall; = idr@ietf.org
>> Subject: Re: [Idr] WG LC for
>> draft-ietf-idr-bgp-enhanced-route-refresh
>>
>> RFCs are written for coders "practiced" in the art"= .
>> If anyone sends an EoRR before the adj-RIB-out is fully populated,=
>>then it's a BUG.
>> This does not need to be said.
>>
>> Personally, I believe a route refresh request should not be honore= d
>>until GR is complete.
>> Also, I don't believe a timer for the receipt of EoRR is necessary= ,
>>because the EoRR is guaranteed.
>> Guaranteed means "unless the session drops first".
>> --
>>
>> Jakob Heitz.
>>
>> ________________________________________
>> From: Chris Hall [chris.hall@highwayman.com]
>> Sent: Saturday, 25 January 2014 11:27 AM
>> To: idr@ietf.org=
>> Cc: Jakob Heitz
>> Subject: RE: [Idr] WG LC for
>> draft-ietf-idr-bgp-enhanced-route-refresh
>>
>> Jakob Heitz wrote (on Fri 24-Jan-2014 at 20:37):
>> ...
>>> Silence means don't do it.
>>
>> Hmmm.... as a principle I'm more comfortable with "that which= isn't
>>prohibited is permitted"....
>>
>>> You would definitely NOT want BoRR to flush old stales.
>>
>> ....but, given the definite requirement, and given that the curren= t
>>precedent for "marking stale" does flush old stale, then = a few words
>>for the avoidance of doubt ?
>>
>>> Restarting the timer might be a good idea.
>>
>> I dunno... a route which remains stale for "a long time"= is, of
>>course, a candidate for being withdrawn: so having started a timer = the
>>first time things are set stale, I would avoid extending that -- at=
>>least for Graceful Restart, where the whole withdraw thing has been= "on-hold"
>>since the last session failed.  For route-refresh I guess ther= e's more
>>of a presumption that stale routes will be refreshed sooner or late= r,
>>and in the meantime they remain good.  So if the route-refresh= is
>>(repeatedly) restarted for some reason, perhaps it is more reasonab= le
>>to extend the flush deadline -- but avoid doing this indefinitely ?=
>>
>> FWIW, for route-refresh and for GR, the Adj-RIB-Out mechanics I ha= ve
>>built in Quagga prioritise route changes (pending changes and any t= hat
>>occur during the refresh) over refresh updates.  This makes it= more
>>likely that remaining stale routes are still good.  But the ot= her end
>>cannot know that.
>>
>> The paragraph in the draft discussing the "entire Adj-RIB-Out= "
>>defines that to be the entries present "at the start of the ro= ute
>>refresh operation", and observes that these comprise both reac= hable
>>and unreachable routes.  [An "of" after "compri= se" sets teeth on edge,
>>BTW.]  I'm really not sure what this paragraph is trying to te= ll me.
>> The reference to unreachable routes appears to suggest that pendin= g
>>withdraws should be sent as part of the refresh -- so not left to t= he
>>EoRR to implement at the end.  The point at which the EoRR is = sent is
>>defined such that it excludes any Adj-RIB-Out entries added after t= he
>>route-refresh started, but includes any which are changed during th= e
>>process.  It seems reasonable to delay any brand new reachable=
>>prefixes until after all previously announced ones have been refres= hed
>>and the EoRR sent -- if that's the intent here.  Changes which= occur
>>before the refresh gets to a given entry are pretty naturally swept= up
>>by the refresh.  Changes which occur after the refresh has gon= e past,
>>could/should be deferred to after the EoRR ?  Does it make a >>difference if the change is a withdraw ?  (Of course MRAI may = kick in here.  Ah.
>>MRAI and route-refresh, there's a topic !)
>>
>> I think the essence of the rule is that the EoRR should be sent on= ce
>>all prefixes previously advertised to the peer as reachable have be= en
>>refreshed, ie announced or withdrawn (at least) once.  Or, per= haps
>>more strictly, not *before* those prefixes have *all* been announce= d
>>once -- given that the EoRR will promptly bang un-advertised stuff = on the head.
>>Even more strictly perhaps: not send EoRR *before* any withdraws
>>implied by it are required or desirable.
>>
>> Depending on the implementation, a given sender may or may not be<= br> >>able to determine the minimum set of updates required before sendin= g EoRR.
>>
>> If the refresh operation takes a long time, there may be good
>>routeing reasons to arrange for some route changes to be sent to th= e peer "early"
>>-- that is to send announcements which do not contribute to the
>>refresh, but which are important enough to warrant delaying the end= of
>>the refresh.  That could be a matter for recommendation(s) in = the standard.
>>
>> NB: given that the timing of the EoRR is tied to the state of the<= br> >>Adj-RIB-Out, I'm not sure about the Graceful Restart assumptions. &= nbsp;At
>>the beginning of the initial update, the Restarting and Receiving >>speakers have:
>>
>>  Restarting:  Empty Adj-RIB-In   Empty Adj-RIB-Out<= br> >>
>>  Receiving:   Empty Adj-RIB-Out  Stale Adj-RIB-In >>
>> Now suppose (bonkers or otherwise) the receiving speaker sends an = RRQ
>>part way through the initial update.  The restarting speaker r= esponds
>>with BoRR, everything in its Adj-RIB-Out, and EoRR -- per specifica= tion.
>> The receiving speaker sees the EoRR, and flushes stale.
>>Unfortunately, if the restarting speaker has not yet fully populate= d
>>its Adj-RIB-Out, then many further routes will be sent before the E= oR
>>falls due -- but the receiving speaker has already flushed their ti= ny
>>posteriors :-(
>>
>> I am coming to the view that route-refresh during a Graceful Resta= rt
>>initial update is a horse of a different colour altogether.
>>
>> [So the assumption that EoRR and EoR are triggered by the same thi= ng
>>was completely wrong, and I apologise for it.]
>>
>> Chris
>>
>> _______________________________________________
>> 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
htt= ps://www.ietf.org/mailman/listinfo/idr

 

 = 

______________________________________________=
___________________________________________________________________________=

 
Ce message et ses pieces jointes peuvent conte=
nir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans au=
torisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pi=
eces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce mess=
age a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain c=
onfidential or privileged information that may be protected by law;
they should not be distributed, used or copied=
 without authorisation.
If you have received this email in error, plea=
se notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable=
 for messages that have been modified, changed or falsified.
Thank you.
______________________________________________=
___________________________________________________________________________=

 
Ce message et ses pieces jointes peuvent conte=
nir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans au=
torisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pi=
eces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce mess=
age a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain c=
onfidential or privileged information that may be protected by law;
they should not be distributed, used or copied=
 without authorisation.
If you have received this email in error, plea=
se notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable=
 for messages that have been modified, changed or falsified.
Thank you.
______________________________________________=
___________________________________________________________________________=

 
Ce message et ses pieces jointes peuvent conte=
nir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans au=
torisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pi=
eces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce mess=
age a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain c=
onfidential or privileged information that may be protected by law;
they should not be distributed, used or copied=
 without authorisation.
If you have received this email in error, plea=
se notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable=
 for messages that have been modified, changed or falsified.
Thank you.

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

______________________________________________________________________=
___________________________________________________

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,
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 authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A070E085APEXCVZYM11corpo_-- From shares@ndzh.com Fri Jan 31 07:39:37 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C30F21A041A for ; Fri, 31 Jan 2014 07:39:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMHUKdegBFp4 for ; Fri, 31 Jan 2014 07:39:31 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 26D071A0376 for ; Fri, 31 Jan 2014 07:39:31 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'idr wg'" References: <00e301cf12b3$df905da0$9eb118e0$@ndzh.com> In-Reply-To: <00e301cf12b3$df905da0$9eb118e0$@ndzh.com> Date: Fri, 31 Jan 2014 10:39:24 -0500 Message-ID: <004801cf1e9a$9ebf5590$dc3e00b0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0049_01CF1E70.B5EA37F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGqegp3VY9AufBbPDp/kp6S5EYRhproQLxg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: draft-ietf-idr-ls-distribution@tools.ietf.org Subject: Re: [Idr] WG LC - for early adoption Code points for draft-ietf-idr-ls-distribution-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 15:39:37 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0049_01CF1E70.B5EA37F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Idr WG: This draft has been approved for early allocation. Most people wanted RFC, but some recommended waiting until further trials have been done. We will forward this to the IESG for early allocation, and ask the authors to bring an implementation update to the IETF in London. Sue From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Thursday, January 16, 2014 7:10 AM To: idr wg Cc: draft-ietf-idr-ls-distribution@tools.ietf.org Subject: [Idr] WG LC - for early adoption Code points for draft-ietf-idr-ls-distribution-04 Hi all In September 2013 the draft authors have asked for a WG LC on early adoption code point. We had only 1 response for support. The authors have requested another WG LC on allowing this draft to have an early adoption code-point. The authors point out that they are in multiple vendor interoperability trials with 3+ implementations. This begins a 2 week WG LC on giving early code points to: https://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ Please comment on the list. It would aid the chairs if you would include in your comments: a) Support early adoption: yes/no b) Draft is ready for WG LC: yes/no Sue and John Co-chairs ------=_NextPart_000_0049_01CF1E70.B5EA37F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Idr WG:

 

This draft has been = approved for early allocation.  Most people wanted RFC, but some = recommended waiting until further trials have been done. =

 

We will forward this to = the IESG for early allocation, and ask the authors to bring an = implementation update to the IETF in London.

 

Sue =

 

From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan = Hares
Sent: Thursday, January 16, 2014 7:10 AM
To: = idr wg
Cc: = draft-ietf-idr-ls-distribution@tools.ietf.org
Subject: [Idr] = WG LC - for early adoption Code points for = draft-ietf-idr-ls-distribution-04

 

Hi all

 

In September 2013  the draft = authors have asked for a WG LC on early adoption code point. We had only = 1 response for support.

 

The authors = have requested another WG LC on allowing this draft to have an early = adoption code-point.  The authors point out that they are in = multiple vendor interoperability trials with 3+ implementations. =

 

This begins = a 2 week WG LC on giving early code points to:

 

https://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/

 

 

Please comment on the list. It would = aid the chairs if you would include in your comments: =

 

a)  Support early adoption: = yes/no

b)  Draft is ready for WG LC: yes/no =

 

 

Sue and John =

Co-chairs =  

 

 

------=_NextPart_000_0049_01CF1E70.B5EA37F0-- From shares@ndzh.com Fri Jan 31 07:46:10 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42F5D1A028B for ; Fri, 31 Jan 2014 07:46:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.845 X-Spam-Level: ** X-Spam-Status: No, score=2.845 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rp6UglEsVpbz for ; Fri, 31 Jan 2014 07:46:09 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 20D081A0280 for ; Fri, 31 Jan 2014 07:46:09 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "idr wg" Date: Fri, 31 Jan 2014 10:45:58 -0500 Message-ID: <005501cf1e9b$89bfdb50$9d3f91f0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0056_01CF1E71.A0EA96A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8emu/fCz/uA2IYSB++8qRmyZW1hA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: draft-rekhter-mdcs@tools.ietf.org, "'John G. Scudder'" Subject: [Idr] Request WG adoption for draft-rekhter-mdrs and draft-rekhter-mdcs X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 15:46:10 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0056_01CF1E71.A0EA96A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit IDR: The following drafts have been accepted by the WG (due to October WG all) https://datatracker.ietf.org/doc/draft-rekhter-mdcs/ https://datatracker.ietf.org/doc/draft-rekhter-mdrs/ Please submit these as: Draft-ietf-idr-mdcs-00 Draft-ietf-idr-mdrs-00 Thank you to Jeff Haas for reminding me that this WG Adoption call had not been posted. Sue Hares ------=_NextPart_000_0056_01CF1E71.A0EA96A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IDR: =

 

The following drafts have been accepted by the WG (due = to October WG all)

 

https://dat= atracker.ietf.org/doc/draft-rekhter-mdcs/

https://dat= atracker.ietf.org/doc/draft-rekhter-mdrs/

 

Please = submit these as:

 

Draft-ietf-idr-mdcs-00

Draft-ietf-idr-mdrs-00

 

Thank you to = Jeff Haas for reminding me that this WG Adoption call had not been = posted.

 

Sue Hares

------=_NextPart_000_0056_01CF1E71.A0EA96A0-- From internet-drafts@ietf.org Fri Jan 31 09:19:53 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43BBC1A0416; Fri, 31 Jan 2014 09:19:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcmxj_pminYu; Fri, 31 Jan 2014 09:19:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B4AFE1A043A; Fri, 31 Jan 2014 09:19:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140131171951.3537.69826.idtracker@ietfa.amsl.com> Date: Fri, 31 Jan 2014 09:19:51 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-aigp-15.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 17:19:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : The Accumulated IGP Metric Attribute for BGP Authors : Pradosh Mohapatra Rex Fernando Eric C. Rosen James Uttaro Filename : draft-ietf-idr-aigp-15.txt Pages : 15 Date : 2014-01-31 Abstract: Routing protocols that have been designed to run within a single administrative domain ("IGPs") generally do so by assigning a metric to each link, and then choosing as the installed path between two nodes the path for which the total distance (sum of the metric of each link along the path) is minimized. BGP, designed to provide routing over a large number of independent administrative domains ("autonomous systems"), does not make its path selection decisions through the use of a metric. It is generally recognized that any attempt to do so would incur significant scalability problems, as well as inter-administration coordination problems. However, there are deployments in which a single administration runs several contiguous BGP networks. In such cases, it can be desirable, within that single administrative domain, for BGP to select paths based on a metric, just as an IGP would do. The purpose of this document is to provide a specification for doing so. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-aigp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-aigp-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-aigp-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/
total number of IPR disclosures found: = 2
2009-06-30
ID # 1159
2009-06-30
ID # 1160