From ilya@nobulus.com Tue Oct 1 03:31:53 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A016821F85EF for ; Tue, 1 Oct 2013 03:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLr8idU1sx4o for ; Tue, 1 Oct 2013 03:31:53 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by ietfa.amsl.com (Postfix) with ESMTP id B32C221F9D22 for ; Tue, 1 Oct 2013 03:31:51 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id 5700A1765C; Tue, 1 Oct 2013 12:31:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id PUCIn7Sy3hj8; Tue, 1 Oct 2013 12:31:47 +0200 (CEST) Received: from xtc100.easynet.global (unknown [87.85.77.32]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by nobulus.com (Postfix) with ESMTPSA id 042D81752F; Tue, 1 Oct 2013 12:31:47 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ilya Varlashkin In-Reply-To: <1401.1380574943@erosen-linux> Date: Tue, 1 Oct 2013 11:31:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1401.1380574943@erosen-linux> To: erosen@cisco.com X-Mailer: Apple Mail (2.1508) Cc: idr wg , "UTTARO, JAMES" , Susan Hares , "John G. Scudder" Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 10:31:53 -0000 On Sep 30, 2013, at 10:02 PM, Eric Rosen wrote: >=20 >> current draft should say how to handle AIGP Types an implementation >> doesn't recognise >=20 > We can add that unrecognized types have no impact on the bestpath > selection. I don't think there's anything more to say about them. >=20 I'm just worried that somebody might "treat them as WITHDRAW", which may = be good or bad thing to do. Perhaps something like: "AIGP attributes = with Type set to a value not recognised by local implementation should = be treated as unknown transitive BGP attribute (per rfc4271)" > With regard to type 1, the draft should probably state what to do if = there > is more than a single type 1 TLV. I propose to add a statement saying = that > an implementation originating an AIGP attribute MUST NOT include more = than > one type 1 TLV, and that an implementation receiving an AIGP attribute = with > more than one type 1 TLV MUST use only the AIGP value in the first = one. >=20 Generally it's a good idea. Though you can't know that first AIGP is any = better than second, and this doesn't even give you deterministic = behaviour because you don't know whether or not broken implementation = will add its own instance of AIGP before or after the one already linked = to a prefix. So on receiving multiple AIGP instances it's probably to = treat the message as malformed and "as WITHDRAW". And this seems to be = reasonable to apply to any Type of AIGP (even those we don't have = today). /iLya From aretana@cisco.com Tue Oct 1 05:13:00 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB1721E80E7 for ; Tue, 1 Oct 2013 05:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8K+jtOAw7zyO for ; Tue, 1 Oct 2013 05:12:56 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6391121E80DE for ; Tue, 1 Oct 2013 05:12:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=803; q=dns/txt; s=iport; t=1380629571; x=1381839171; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=GVArD+isxSE3CdczUK34u1Vt9jXhkVsAIcEJpzMsOzM=; b=jDtzU9uFuvfRILF2J9wAUVQm/2SjGdIJlp4OASIGJZ2ywioBEtWYnE1V uTF3QcHomFOCE5FHfXhUxFDi0Yrv0OV/u29Vnj4edx3I+nrNhCz+rAjf8 vOQig1mMRa1V3cMxlKcJHqLBCkb8Hs3ZLkC3hR5zI24Do4auUdnvX2QO0 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAPC6SlKtJV2d/2dsb2JhbABagwc4UsECgS8WdIInAQQdHT8SAQgiFEIlAgQOBQgMB4drDLxTjyAxB4MfgQMDmS6QS4Mkgio X-IronPort-AV: E=Sophos;i="4.90,1013,1371081600"; d="scan'208";a="266432464" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 01 Oct 2013 12:12:51 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r91CCokg030030 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 1 Oct 2013 12:12:50 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.229]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Tue, 1 Oct 2013 07:12:50 -0500 From: "Alvaro Retana (aretana)" To: Ilya Varlashkin Thread-Topic: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) Thread-Index: AQHOu66hoZDNOu+SQiq0dAmRJ9YB/pnf2HqA Date: Tue, 1 Oct 2013 12:12:49 +0000 Message-ID: In-Reply-To: <15822.1380306195@erosen-linux> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.7] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: idr wg , "Eric Rosen \(erosen\)" , Susan Hares , "John G. Scudder" Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 12:13:00 -0000 Hi! I just want to point out that we already have a WG document that has the characteristics that (I think) have been discussed: flexible POI, transitive, etc.. http://tools.ietf.org/html/draft-ietf-idr-custom-decision IMHO, we should use the cost community since it is the general solution for the problem. Now, that the cost community is not in WGLC, would be a good time to review its applicability to the other use cases. My 1c. Alvaro. On 9/27/13 2:23 PM, "Eric Rosen (erosen)" wrote: >> >>Is the above something that IDR should consider for amending the draft? > >I think it would be much better to leave the AIGP draft as is, and for >someone to write a new draft, possibly updating the AIGP draft, that >specifies the option you want. > From ilya@nobulus.com Tue Oct 1 05:31:26 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F51211E80DC for ; Tue, 1 Oct 2013 05:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhOGI-O3Kq-C for ; Tue, 1 Oct 2013 05:31:25 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by ietfa.amsl.com (Postfix) with ESMTP id AC7EF21E80F4 for ; Tue, 1 Oct 2013 05:31:04 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id 326AE176B2; Tue, 1 Oct 2013 14:31:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id fh5N0GpD8D9O; Tue, 1 Oct 2013 14:31:00 +0200 (CEST) Received: from xtc100.easynet.global (unknown [87.85.77.32]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by nobulus.com (Postfix) with ESMTPSA id 89A811752F; Tue, 1 Oct 2013 14:31:00 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ilya Varlashkin In-Reply-To: Date: Tue, 1 Oct 2013 13:31:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <81C7AAD1-362B-4915-831A-72FDC6C2C583@nobulus.com> References: To: Alvaro Retana (aretana) X-Mailer: Apple Mail (2.1508) Cc: idr wg , "Eric Rosen \(erosen\)" , Susan Hares , "John G. Scudder" Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 12:31:26 -0000 On Oct 1, 2013, at 1:12 PM, Alvaro Retana (aretana) = wrote: > Hi! >=20 > I just want to point out that we already have a WG document that has = the > characteristics that (I think) have been discussed: flexible POI, > transitive, etc.. >=20 > http://tools.ietf.org/html/draft-ietf-idr-custom-decision >=20 > IMHO, we should use the cost community since it is the general = solution > for the problem. >=20 I have considered cost-community as well (along with AIGP and few other = options) for my scenario - it's lacking rules about what to do at the AS = boundaries (accumulating IGP cost). /iLya From aretana@cisco.com Tue Oct 1 06:01:33 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 785A921E818E for ; Tue, 1 Oct 2013 06:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DTnly6l7PeI for ; Tue, 1 Oct 2013 06:01:28 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8DD21E81E9 for ; Tue, 1 Oct 2013 06:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1136; q=dns/txt; s=iport; t=1380632465; x=1381842065; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=4uJ61AB5X0RY2XURTlmnLHGFSAVtMTzkpVQL9OK5JuI=; b=WNyzguzipANHgXv2sLeoaJbj3ddHM71V6cpWfEK9l4sNRztlvH02bmcx cZCAp7bWcJkKrdM4NE3dLzpl+2JDjK3wYQxEsraGs1uxRmrelHNRtiN1+ wsi6fF1cTyOL8Mh6mcUUc1BWd7+ijL7LRtnXb0zSuRDyJbA2J2LaTR/lF 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAKHGSlKtJV2Y/2dsb2JhbABagweBCsECgS8WdIInAQQdHS0SEgEIIhRCJQIEDgUIDIdyvE+PIDEHgx+BAwOpeYMkgio X-IronPort-AV: E=Sophos;i="4.90,1013,1371081600"; d="scan'208";a="266450746" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 01 Oct 2013 13:01:04 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r91D14Ip028847 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 1 Oct 2013 13:01:04 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.229]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Tue, 1 Oct 2013 08:01:04 -0500 From: "Alvaro Retana (aretana)" To: Ilya Varlashkin Thread-Topic: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) Thread-Index: AQHOu66hoZDNOu+SQiq0dAmRJ9YB/pnf2HqAgABIKAD//8VRAA== Date: Tue, 1 Oct 2013 13:01:03 +0000 Message-ID: In-Reply-To: <81C7AAD1-362B-4915-831A-72FDC6C2C583@nobulus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.7] Content-Type: text/plain; charset="us-ascii" Content-ID: <3440C4D6519C1242A92DA526F5228F15@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: idr wg , "Eric Rosen \(erosen\)" , Susan Hares , "John G. Scudder" Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 13:01:33 -0000 On 10/1/13 8:31 AM, "Ilya Varlashkin" wrote: Ilya: >I have considered cost-community as well (along with AIGP and few other >options) for my scenario - it's lacking rules about what to do at the AS >boundaries (accumulating IGP cost). The cost community carries a Cost that can be interpreted by the operator as it relates to the Community-ID (and even the POI). In that sense it is just like any other community: the cost in it is relevant to your application.=20 That is why the draft doesn't talk about what to specifically do with the values put in it because some applications (AIGP-like, for example) will want to accumulate while others may want to do something completely different. This is true not only for the behavior at an AS boundary, but for any other place where the value may want to be changed (RR, for instance). The current draft specifies the format and general operation. The handling of the Cost can either be specified in a separate draft, or it could be just interpreted/agreed to locally based on the ID (just like any other community). Thanks! Alvaro. From ilya@nobulus.com Tue Oct 1 06:10:36 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AABC21E8147 for ; Tue, 1 Oct 2013 06:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDoKOA88Z+XH for ; Tue, 1 Oct 2013 06:10:35 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC8011E81A8 for ; Tue, 1 Oct 2013 06:06:37 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id 5DBBD17665; Tue, 1 Oct 2013 15:06:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id kkMLoT7WyIKz; Tue, 1 Oct 2013 15:06:33 +0200 (CEST) Received: from xtc100.easynet.global (unknown [87.85.77.32]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by nobulus.com (Postfix) with ESMTPSA id 30DFF17516; Tue, 1 Oct 2013 15:06:33 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ilya Varlashkin In-Reply-To: Date: Tue, 1 Oct 2013 14:06:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Alvaro Retana (aretana) X-Mailer: Apple Mail (2.1508) Cc: idr wg , "Eric Rosen \(erosen\)" , Susan Hares , "John G. Scudder" Subject: Re: [Idr] WG Last call for draft-ietf-idr-aigp-10 (ending 9/27/13) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 13:10:36 -0000 On Oct 1, 2013, at 2:01 PM, Alvaro Retana (aretana) = wrote: > On 10/1/13 8:31 AM, "Ilya Varlashkin" wrote: >=20 > Ilya: >=20 >> I have considered cost-community as well (along with AIGP and few = other >> options) for my scenario - it's lacking rules about what to do at the = AS >> boundaries (accumulating IGP cost). >=20 > The cost community carries a Cost that can be interpreted by the = operator > as it relates to the Community-ID (and even the POI). In that sense = it is > just like any other community: the cost in it is relevant to your > application.=20 >=20 let's not mix this here into AIGP discussion. I'm happy to discuss cost = community with you either in a separate mail at IDR list or privately. /iLya= From russw@riw.us Tue Oct 1 06:39:16 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9829E11E825F for ; Tue, 1 Oct 2013 06:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[AWL=0.687, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Td2ruRAmNc0N for ; Tue, 1 Oct 2013 06:39:11 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) by ietfa.amsl.com (Postfix) with ESMTP id 0C64211E8240 for ; Tue, 1 Oct 2013 06:36:33 -0700 (PDT) Received: from cpe-098-122-147-095.nc.res.rr.com ([98.122.147.95]:63313 helo=RussPC) by server.riw.us with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VR07o-00036N-D2; Tue, 01 Oct 2013 13:36:28 +0000 From: "Russ White" To: "'Ronald Bonica'" , References: <6fd9586a238746b19965623c881aa919@CO1PR05MB442.namprd05.prod.outlook.com> In-Reply-To: <6fd9586a238746b19965623c881aa919@CO1PR05MB442.namprd05.prod.outlook.com> Date: Tue, 1 Oct 2013 09:36:33 -0400 Message-ID: <026501cebeab$3f294f40$bd7bedc0$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQEHO3+GHagMAjXgL8v2gERdrryDXJtu33Vw Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Idr] Request WG adoption for draft-rekhter-mdrs and draft-rekhter-mdcs X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 13:39:17 -0000 Support. Russ > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of > Ronald Bonica > Sent: Monday, September 30, 2013 3:17 PM > To: idr@ietf.org List > Subject: Re: [Idr] Request WG adoption for draft-rekhter-mdrs and draft- > rekhter-mdcs > > Also support > > >> Jeff: > >> > >> The adoption request will be open for 2 weeks (9/23 - 10/7/13) for: > >> > >> draft-rekhter-mdcs - Multicast Distribution Control Signaling > >> draft-rekhter-mdrs - Multicast Distribution Reachability Signaling > >> > >> Sue > > -------------------------- > Ron Bonica > vcard: www.bonica.org/ron/ronbonica.vcf > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From marco@juniper.net Tue Oct 1 08:29:52 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 914FD21E808D for ; Tue, 1 Oct 2013 08:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.359 X-Spam-Level: X-Spam-Status: No, score=-4.359 tagged_above=-999 required=5 tests=[AWL=2.240, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-jWhblo1Fai for ; Tue, 1 Oct 2013 08:29:46 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5AA21E81B5 for ; Tue, 1 Oct 2013 08:29:25 -0700 (PDT) Received: from mail20-co9-R.bigfish.com (10.236.132.232) by CO9EHSOBE042.bigfish.com (10.236.130.105) with Microsoft SMTP Server id 14.1.225.22; Tue, 1 Oct 2013 15:29:12 +0000 Received: from mail20-co9 (localhost [127.0.0.1]) by mail20-co9-R.bigfish.com (Postfix) with ESMTP id ED537320135 for ; Tue, 1 Oct 2013 15:29:11 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(zzbb2dI98dI9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h186068h8275bh8275dhz2fh2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h) Received-SPF: pass (mail20-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=marco@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(479174003)(24454002)(13464003)(189002)(51704005)(199002)(76786001)(81816001)(76796001)(47976001)(50986001)(47736001)(49866001)(79102001)(56776001)(56816003)(54316002)(76176001)(76482001)(81686001)(59766001)(46102001)(77982001)(53806001)(51856001)(83506001)(80976001)(77096001)(19580405001)(83322001)(19580395003)(74366001)(65816001)(54356001)(69226001)(66066001)(83072001)(63696002)(4396001)(36756003)(80022001)(81342001)(31966008)(74706001)(74502001)(47446002)(74876001)(81542001)(74662001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB074; H:BN1PR05MB075.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail20-co9 (localhost.localdomain [127.0.0.1]) by mail20-co9 (MessageSwitch) id 1380641350837507_28994; Tue, 1 Oct 2013 15:29:10 +0000 (UTC) Received: from CO9EHSMHS001.bigfish.com (unknown [10.236.132.244]) by mail20-co9.bigfish.com (Postfix) with ESMTP id BE98E4C00A2 for ; Tue, 1 Oct 2013 15:29:10 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS001.bigfish.com (10.236.130.11) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 1 Oct 2013 15:29:05 +0000 Received: from BN1PR05MB074.namprd05.prod.outlook.com (10.255.199.12) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.359.1; Tue, 1 Oct 2013 15:29:00 +0000 Received: from BN1PR05MB075.namprd05.prod.outlook.com (10.255.199.21) by BN1PR05MB074.namprd05.prod.outlook.com (10.255.199.12) with Microsoft SMTP Server (TLS) id 15.0.775.9; Tue, 1 Oct 2013 15:28:58 +0000 Received: from BN1PR05MB075.namprd05.prod.outlook.com ([169.254.11.10]) by BN1PR05MB075.namprd05.prod.outlook.com ([169.254.11.10]) with mapi id 15.00.0775.005; Tue, 1 Oct 2013 15:28:58 +0000 From: Marco Rodrigues To: "idr@ietf.org" Thread-Topic: [Idr] Request WG adoption for draft-rekhter-mdrs and draft-rekhter-mdcs Thread-Index: AQHOvrryfqF5RXcfGUetA3uEUrHzDQ== Date: Tue, 1 Oct 2013 15:28:57 +0000 Message-ID: In-Reply-To: <015201cebbca$30e00a20$92a01e60$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [66.129.232.2] x-forefront-prvs: 09860C2161 Content-Type: text/plain; charset="us-ascii" Content-ID: <815118DEBF775949BF8E16239A6148A7@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [Idr] Request WG adoption for draft-rekhter-mdrs and draft-rekhter-mdcs X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 15:29:52 -0000 Support both draft-rekhter-mdcs and draft-rekhter-mdrs. Marco.=20 On 9/27/13 5:40 PM, "Susan Hares" wrote: >Jeff: > >The adoption request will be open for 2 weeks (9/23 - 10/7/13) for: > >draft-rekhter-mdcs - Multicast Distribution Control Signaling >draft-rekhter-mdrs - Multicast Distribution Reachability Signaling > >Sue=20 > >-----Original Message----- >From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of >Jeffrey Haas >Sent: Monday, September 23, 2013 3:52 PM >To: idr@ietf.org >Subject: [Idr] Request WG adoption for draft-rekhter-mdrs and >draft-rekhter-mdcs > >The authors of the following two drafts would like to request adoption of >these drafts by the IDR working group: > >draft-rekhter-mdcs - Multicast Distribution Control Signaling >draft-rekhter-mdrs - Multicast Distribution Reachability Signaling > >draft-rekhter-geo-distribution will be seeking adoption in mboned. > >These drafts were presented at the IDR session at the IETF 87 in Berlin. > >As noted during the presentation, the primary goal of soliciting WG >adoption >is to get WG review of the drafts. The drafts primarily request >additional >SAFI codepoints while also noting an application of the RFC 5575 BGP >Flowspec encoding for use in multicast control plane filtering. > >-- Jeff (for the authors) >_______________________________________________ >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 Wed Oct 2 14:15:55 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BEE421F9EAF; Wed, 2 Oct 2013 14:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnmu7KD9AJm2; Wed, 2 Oct 2013 14:15:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6D321F85D1; Wed, 2 Oct 2013 14:13:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.72.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131002211359.20697.4560.idtracker@ietfa.amsl.com> Date: Wed, 02 Oct 2013 14:13:59 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-legacy-rtc-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 21:15:55 -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 : Automatic Route Target Filtering for legacy PEs Author(s) : Pradosh Mohapatra Arjun Sreekantiah Keyur Patel Burjiz Pithawala Alton Lo Filename : draft-ietf-idr-legacy-rtc-02.txt Pages : 10 Date : 2013-10-02 Abstract: This document describes a simple procedure that allows "legacy" BGP speakers to exchange route target membership information in BGP without using mechanisms specified in [RFC4684]. The intention of the proposed technique is to help in partial deployment scenarios and is not meant to replace [RFC4684]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-legacy-rtc There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-legacy-rtc-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-legacy-rtc-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 jgs@juniper.net Tue Oct 8 14:17:56 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BBD211E8102 for ; Tue, 8 Oct 2013 14:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0v-yWZ9VM8BL for ; Tue, 8 Oct 2013 14:17:51 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id 1506621F8D0B for ; Tue, 8 Oct 2013 14:17:51 -0700 (PDT) Received: from mail95-co1-R.bigfish.com (10.243.78.235) by CO1EHSOBE001.bigfish.com (10.243.66.64) with Microsoft SMTP Server id 14.1.225.22; Tue, 8 Oct 2013 21:17:49 +0000 Received: from mail95-co1 (localhost [127.0.0.1]) by mail95-co1-R.bigfish.com (Postfix) with ESMTP id F1B8F1A01C3 for ; Tue, 8 Oct 2013 21:17:48 +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: -11 X-BigFish: VPS-11(zzda00h4015Idc73hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzz1033IL17326ah1de097h186068h8275dh17598djz2fh2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h2052h20b3m1155h) Received-SPF: pass (mail95-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jgs@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(199002)(164054003)(74876001)(558084003)(74366001)(85306002)(36756003)(74706001)(81816001)(15975445006)(33656001)(82746002)(76786001)(76796001)(56816003)(4396001)(76176001)(47736001)(50986001)(47976001)(49866001)(81686001)(77096001)(65816001)(15202345003)(83072001)(69226001)(56776001)(66066001)(80022001)(76482001)(54316002)(81542001)(79102001)(63696002)(59766001)(77982001)(81342001)(51856001)(80976001)(31966008)(47446002)(46102001)(74502001)(74662001)(54356001)(53806001)(83322001)(19580395003)(83716002)(42262001)(15302535010); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB527; H:DM2PR05MB527.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail95-co1 (localhost.localdomain [127.0.0.1]) by mail95-co1 (MessageSwitch) id 1381267028513179_21667; Tue, 8 Oct 2013 21:17:08 +0000 (UTC) Received: from CO1EHSMHS019.bigfish.com (unknown [10.243.78.250]) by mail95-co1.bigfish.com (Postfix) with ESMTP id 797D420217 for ; Tue, 8 Oct 2013 21:17:08 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS019.bigfish.com (10.243.66.29) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 8 Oct 2013 21:17:08 +0000 Received: from DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.371.2; Tue, 8 Oct 2013 21:17:08 +0000 Received: from DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) by DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) with Microsoft SMTP Server (TLS) id 15.0.775.9; Tue, 8 Oct 2013 21:17:05 +0000 Received: from DM2PR05MB527.namprd05.prod.outlook.com ([169.254.6.207]) by DM2PR05MB527.namprd05.prod.outlook.com ([169.254.6.207]) with mapi id 15.00.0775.005; Tue, 8 Oct 2013 21:17:05 +0000 From: John Scudder To: "idr@ietf. org" Thread-Topic: WG adoption requested for draft-ga-idr-as-migration Thread-Index: AQHOxGu8DOc0lAkTdUGn+RAbVFtCqQ== Date: Tue, 8 Oct 2013 21:17:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0993689CD1 Content-Type: text/plain; charset="us-ascii" Content-ID: <940B7DC6993B6E45B78A9FDC8F91D294@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [Idr] WG adoption requested for draft-ga-idr-as-migration X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 21:17:56 -0000 Folks, The authors have requested IDR adopt draft-ga-idr-as-migration as a working= group document.=20 http://datatracker.ietf.org/doc/draft-ga-idr-as-migration/ Please send any comments to the list by October 23. Thanks, --John From bill.wu@huawei.com Thu Oct 10 03:14:34 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F97721E8172 for ; Thu, 10 Oct 2013 03:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kDAvMGgKU38r for ; Thu, 10 Oct 2013 03:14:30 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8FC21E80ED for ; Thu, 10 Oct 2013 03:14:26 -0700 (PDT) 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 AWR17344; Thu, 10 Oct 2013 10:14:25 +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.146.0; Thu, 10 Oct 2013 11:13:55 +0100 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 10 Oct 2013 11:14:21 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.141]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0146.000; Thu, 10 Oct 2013 18:14:13 +0800 From: Qin Wu To: idr wg Thread-Topic: I-D Action: draft-wu-idr-te-pm-bgp-02.txt Thread-Index: AQHOxZ/kQMKnsmZtUUO+ZaKi/onlZZnttJOg Date: Thu, 10 Oct 2013 10:14:12 +0000 Message-ID: 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [Idr] FW: I-D Action: draft-wu-idr-te-pm-bgp-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 10:14:34 -0000 Hi, IDRers: Here is the update of BGP distribution for Traffic engineering performance = metrics draft (http://tools.ietf.org/html/draft-wu-idr-te-pm-bgp-02) Based on Berlin IDR meeting discussion and offline discussion with ISIS-TE-= extension authors. Thanks for Hannes for helping let this discussion happen. The changes compared to the previous version includes: o Taking out link utilization metric and channel throughput metric from this version and will add link utilization metric back to the the next version when there was agreement on what measurement unit is= used for link utilization. o Some additional texts in BGP extension section 4 to explain how to position 'A' bit in the BGP TE performance TLV. o Add two editor notes to explain the status of this draft and open issue that need be resolved. o Some additional text in the use case sections to clarify how to use these TE performance metrics. It seems We have reached rough agreement with ISIS/OSPF-TE-extension author= on the format and semantic of link utilization metric That will be added to ISIS/OSPF-TE-extension draft. But it still needs to w= ait the update of the dependent draft(i.e.,ISIS-TE-extension draft) And then add link utilization metric into this draft. The diff is http://www.ietf.org/rfcdiff?url2=3Ddraft-wu-idr-te-pm-bgp-02 Regards! -Qin -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] = On Behalf Of internet-drafts@ietf.org Sent: Thursday, October 10, 2013 6:03 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-wu-idr-te-pm-bgp-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : BGP attribute for North-Bound Distribution of Traffic En= gineering (TE) performance Metrics Author(s) : Qin Wu Danhua Wang Stefano Previdi Hannes Gredler Saikat Ray Filename : draft-wu-idr-te-pm-bgp-02.txt Pages : 14 Date : 2013-10-10 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, and available bandwidth). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-wu-idr-te-pm-bgp There's also a htmlized version available at: http://tools.ietf.org/html/draft-wu-idr-te-pm-bgp-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-wu-idr-te-pm-bgp-02 Please note that it may take a couple of minutes from the time of submissio= n 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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From bruno.decraene@orange.com Thu Oct 10 05:45:23 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C34B21E8115 for ; Thu, 10 Oct 2013 05:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekwNuZze5W4Q for ; Thu, 10 Oct 2013 05:45:10 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 7281C11E815F for ; Thu, 10 Oct 2013 05:45:06 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 383C118CB1E for ; Thu, 10 Oct 2013 14:45:05 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id EF49F238048 for ; Thu, 10 Oct 2013 14:45:04 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Thu, 10 Oct 2013 14:45:04 +0200 From: To: idr wg Thread-Topic: draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHOxbaKqDTLsKyCeka1DYxEyTqFhQ== Date: Thu, 10 Oct 2013 12:45:03 +0000 Message-ID: <6777_1381409105_5256A151_6777_146_1_53C29892C857584299CBF5D05346208A0706B4BE@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <02b901ceb0b7$e1d74b90$a585e2b0$@ndzh.com> <25182_1380115164_5242E2DC_25182_16908_1_53C29892C857584299CBF5D05346208A0706195C@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <25182_1380115164_5242E2DC_25182_16908_1_53C29892C857584299CBF5D05346208A0706195C@PEXCVZYM11.corporate.adroot.infra.ftgroup> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.27.82422 Subject: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 12:45:23 -0000 Hi all, The draft may have two different goals: -a- systematic but light checks for refreshing purpose -b- "on demand" but extensive checks for troubleshooting/debugging purpose Because If we want to do a full check ("b"), i.e. determine which BGP routi= ng information has not been reflected, we may need to define a real "snapsh= ot" and only sends the update related to this snapshot between the 2 new de= marcation messages. The drawback is that during this time, the BGP convergence is slow down bec= ause "real time" BGP updates needs to wait for the end of this snapshot. An= d this can be long (minutes, ten of minutes). Hence IMO, this is not advisa= ble for all (existing) Route Refresh. I would rather limit such behavior to= specific "on demand" request (e.g. through a new RR request sub-type) OTOH, if we just want to "refresh" the routes ("a"), i.e. know when to purg= e the non-received one, we can interleave live BGP updates during the refre= sh. This does not delay BGP convergence but we won't be able to detect if t= here were inconsistencies and what they were.=20 IMO, the draft would need to take a position between both options. Eventual= ly, it could be extended to cover both, if there is a desire for this. If only "a" is needed, I'm not sure to see the value of the "begin" demarca= tion message, as the sender of RR could locally mark its route when sending= the RR, rather than when receiving the "RR Start" Thank you, Bruno ___________________________________________________________________________= ______________________________________________ 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 rraszuk@gmail.com Thu Oct 10 09:10:13 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE3E11E8186 for ; Thu, 10 Oct 2013 09:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLHBajg1xOb0 for ; Thu, 10 Oct 2013 09:10:12 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 4A49521E811B for ; Thu, 10 Oct 2013 09:10:09 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id at1so5649283iec.30 for ; Thu, 10 Oct 2013 09:10:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=KQTTmSH5p3eeaW1jtl0wz3g1Z/pSwBYQEPUlGI+HY/8=; b=Hs2hzjn7QwUlc8Ok7gOW5o3bnGBFKK9hGZzIT3U+Ke7mbbtjuh8rheVeRmo1t2Mad1 BtCXHocXew/i8TSvI4N0j9GHUAyh6AUHr5flrkJPAnHVWz3mB885//XZJwuq+FYXIfQ7 eg00M69rlhxfqCgOEjTCLMIlQWqi7Z0VHVpjheKexYVEd/XsUpuvsGSHP7e47aTQkZzp S/dETKfcQN0KADhbaG0TSc+sl3vjurpCGry7dWmkSkJ9yO6GyEOjfvJurdsI+l+N510j lVBfmNav+0GATj+43OkxtD7oUP0TL+dT61pn/G9CxcjJHUBJaWLy/PLYZw7LkcTx80SZ OSow== MIME-Version: 1.0 X-Received: by 10.50.27.9 with SMTP id p9mr6972607igg.53.1381421409194; Thu, 10 Oct 2013 09:10:09 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.61.129 with HTTP; Thu, 10 Oct 2013 09:10:09 -0700 (PDT) In-Reply-To: <6777_1381409105_5256A151_6777_146_1_53C29892C857584299CBF5D05346208A0706B4BE@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <02b901ceb0b7$e1d74b90$a585e2b0$@ndzh.com> <25182_1380115164_5242E2DC_25182_16908_1_53C29892C857584299CBF5D05346208A0706195C@PEXCVZYM11.corporate.adroot.infra.ftgroup> <6777_1381409105_5256A151_6777_146_1_53C29892C857584299CBF5D05346208A0706B4BE@PEXCVZYM11.corporate.adroot.infra.ftgroup> Date: Thu, 10 Oct 2013 18:10:09 +0200 X-Google-Sender-Auth: O6Iy8UrkPTY-7Nl-r-U-6JhrU5A Message-ID: From: Robert Raszuk To: Bruno Decraene Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: idr wg Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 16:10:13 -0000 Hi Bruno, Let me observe that BGP Operation Message has been proposed to address "a" http://tools.ietf.org/html/draft-ietf-idr-operational-message-00 I would leave bgp enhanced route refresh to address "b" regardless how heavy weight it may sound .. IMHO it is required. >From implementation point of view the demarcation point is only required at the receiver of the updates replay. The sender is free to send new updates during the replay the same way in regular route refresh as with enhanced route refresh .. I see no difference there at all. There is no need for any "snapshot" on the BGP speaker which replays the updates. In fact the draft says the above in this sentence already giving an implementation hint: "When a route entry in the "ADJ-RIB-Out" changes, the advertisement of the modified route entry (instead of the snapshot entry) would suffice. Best, R. On Thu, Oct 10, 2013 at 2:45 PM, wrote: > Hi all, > > The draft may have two different goals: > -a- systematic but light checks for refreshing purpose > -b- "on demand" but extensive checks for troubleshooting/debugging purpos= e > > Because If we want to do a full check ("b"), i.e. determine which BGP rou= ting information has not been reflected, we may need to define a real "snap= shot" and only sends the update related to this snapshot between the 2 new = demarcation messages. > The drawback is that during this time, the BGP convergence is slow down b= ecause "real time" BGP updates needs to wait for the end of this snapshot. = And this can be long (minutes, ten of minutes). Hence IMO, this is not advi= sable for all (existing) Route Refresh. I would rather limit such behavior = to specific "on demand" request (e.g. through a new RR request sub-type) > > OTOH, if we just want to "refresh" the routes ("a"), i.e. know when to pu= rge the non-received one, we can interleave live BGP updates during the ref= resh. This does not delay BGP convergence but we won't be able to detect if= there were inconsistencies and what they were. > > IMO, the draft would need to take a position between both options. Eventu= ally, it could be extended to cover both, if there is a desire for this. > If only "a" is needed, I'm not sure to see the value of the "begin" demar= cation message, as the sender of RR could locally mark its route when sendi= ng the RR, rather than when receiving the "RR Start" > > Thank you, > Bruno > > _________________________________________________________________________= ________________________________________________ > > 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 From internet-drafts@ietf.org Thu Oct 10 16:43:43 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CDF511E81AC; Thu, 10 Oct 2013 16:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EP0eaFjHBSfF; Thu, 10 Oct 2013 16:43:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C2911E81A8; Thu, 10 Oct 2013 16:43:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131010234340.855.27442.idtracker@ietfa.amsl.com> Date: Thu, 10 Oct 2013 16:43:40 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-rfd-usable-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 23:43:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : Making Route Flap Damping Usable Author(s) : Cristel Pelsser Randy Bush Keyur Patel Pradosh Mohapatra Olaf Maennel Filename : draft-ietf-idr-rfd-usable-04.txt Pages : 7 Date : 2013-10-10 Abstract: Route Flap Damping (RFD) was first proposed to reduce BGP churn in routers. Unfortunately, RFD was found to severely penalize sites for being well-connected because topological richness amplifies the number of update messages exchanged. Many operators have turned RFD off. Based on experimental measurement, this document recommends adjusting a few RFD algorithmic constants and limits, to reduce the high risks with RFD, with the result being damping a non-trivial amount of long term churn without penalizing well-behaved prefixes' normal convergence process. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-rfd-usable There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-rfd-usable-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-rfd-usable-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 randy@psg.com Thu Oct 10 16:55:37 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B5121E8154 for ; Thu, 10 Oct 2013 16:55:37 -0700 (PDT) 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=[AWL=0.159, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjdlJ-1sNmwh for ; Thu, 10 Oct 2013 16:55:37 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id CC4B421E8162 for ; Thu, 10 Oct 2013 16:55:34 -0700 (PDT) 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 1VUQ4r-0001C7-OA for idr@ietf.org; Thu, 10 Oct 2013 23:55:34 +0000 Date: Fri, 11 Oct 2013 08:55:32 +0900 Message-ID: From: Randy Bush To: IDR WG In-Reply-To: <20131010234340.855.27442.idtracker@ietfa.amsl.com> References: <20131010234340.855.27442.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Subject: Re: [Idr] I-D Action: draft-ietf-idr-rfd-usable-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 23:55:38 -0000 i think this got all the LC comments and the iesg requests. randy > 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 : Making Route Flap Damping Usable > Author(s) : Cristel Pelsser > Randy Bush > Keyur Patel > Pradosh Mohapatra > Olaf Maennel > Filename : draft-ietf-idr-rfd-usable-04.txt > Pages : 7 > Date : 2013-10-10 > > Abstract: > Route Flap Damping (RFD) was first proposed to reduce BGP churn in > routers. Unfortunately, RFD was found to severely penalize sites for > being well-connected because topological richness amplifies the > number of update messages exchanged. Many operators have turned RFD > off. Based on experimental measurement, this document recommends > adjusting a few RFD algorithmic constants and limits, to reduce the > high risks with RFD, with the result being damping a non-trivial > amount of long term churn without penalizing well-behaved prefixes' > normal convergence process. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-rfd-usable > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-idr-rfd-usable-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-rfd-usable-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/ > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From bruno.decraene@orange.com Fri Oct 11 01:15:57 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D30621F8D20 for ; Fri, 11 Oct 2013 01:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xcwC8DyGFTs6 for ; Fri, 11 Oct 2013 01:15:53 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id B8B9F21F90A7 for ; Fri, 11 Oct 2013 01:15:43 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 790CA2AC296; Fri, 11 Oct 2013 10:15:32 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 536A615804E; Fri, 11 Oct 2013 10:15:32 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Fri, 11 Oct 2013 10:15:32 +0200 From: To: Robert Raszuk Thread-Topic: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHOxdMycsvnJwdZokqbyn8GN4d0RJnvIJlQ Date: Fri, 11 Oct 2013 08:15:31 +0000 Message-ID: <31600_1381479332_5257B3A4_31600_17759_1_53C29892C857584299CBF5D05346208A0706BB34@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <02b901ceb0b7$e1d74b90$a585e2b0$@ndzh.com> <25182_1380115164_5242E2DC_25182_16908_1_53C29892C857584299CBF5D05346208A0706195C@PEXCVZYM11.corporate.adroot.infra.ftgroup> <6777_1381409105_5256A151_6777_146_1_53C29892C857584299CBF5D05346208A0706B4BE@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.10.11.55414 Cc: idr wg Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 08:15:57 -0000 Robert, >From: Robert Raszuk >Sent: Thursday, October 10, 2013 6:10 PM > >Hi Bruno, > >Let me observe that BGP Operation Message has been proposed to address >"a" http://tools.ietf.org/html/draft-ietf-idr-operational-message-00 > >I would leave bgp enhanced route refresh to address "b" regardless how >heavy weight it may sound .. IMHO it is required. Speaking of requirements, it would be good for the draft to document them, = in order for the WG to be able to understand the tradeoffs. Current text is not specific enough: - "The enhancement can be used to facilitate on-line, non-disruptive consis= tency validations of BGP routing updates." - "It is sometimes necessary to perform routing consistency validations suc= h as checking for possible missing withdraws between BGP speakers" e.g.: - is checking for missing updates or missing/incorrect attributes a require= ment? - is delaying routing convergence during all Route Refresh acceptable? As a= reminder, in BGP/MPLS environment, Route Refresh are pretty common and are= typically automatically issued by a PE when a new VRF/VPN/RT is configured= .=20 >From implementation point of view the demarcation point is only >required at the receiver of the updates replay. The sender is free to >send new updates during the replay the same way in regular route >refresh as with enhanced route refresh .. I see no difference there at >all. There is no need for any "snapshot" on the BGP speaker which >replays the updates. What is needed or not depend on the requirements. Cf above point. If you want to be able to "perform routing consistency validations" and det= ect a missed update, you need to exclude "new" updates during the route ref= resh process. Otherwise, the receiver won't be able to know whether this ne= w/unexpected update (i.e. not locally present when he received the RR START= ) is due to a missed one (i.e. you have detected an routing inconsistency) = or a new normal one. >In fact the draft says the above in this sentence already giving an >implementation hint: > > "When a route entry in the "ADJ-RIB-Out" changes, the advertisement of > the modified route entry (instead of the snapshot entry) would suffice. Yes, and as a consequence, we this exclude the ability to detect missed upd= ate. Also, given nothing is said about withdraw, I read that the sender is not a= llowed to send live withdraw between RR start and RR stop, which delay the = routing convergence by minutes. As a reminder, in BGP/MPLS environment, exp= licit withdraw are required as implicit withdraw is not an option (with a u= nique RD policy) and neither advertising the external interface in the IGP. So to sum up, although I understand that trade-offs are required, the curre= nt text seems to get the drawbacks of both option a & b: - delaying routing convergence by minutes during normal network operation t= ime (i.e. not only during troubleshooting) - not allowing to detect missing updates and missing or incorrect attributes So I'd like to see what the requirements were/are. At least, that does not = seem to match mine. At the very minimum, the document needs to clearly spell out such limitatio= ns. Because if it's difficult to troubleshoot where/why a BGP update has be= en missed, it will probably be harder to troubleshoot where/why a BGP conve= rgence has been delayed by minutes (harder because at troubleshooting time,= the problematic states have been erased). Thank you. Bruno > >Best, >R. > > > > > >On Thu, Oct 10, 2013 at 2:45 PM, wrote: >> Hi all, >> >> The draft may have two different goals: >> -a- systematic but light checks for refreshing purpose >> -b- "on demand" but extensive checks for troubleshooting/debugging purpo= se >> >> Because If we want to do a full check ("b"), i.e. determine which BGP >routing information has not been reflected, we may need to define a real >"snapshot" and only sends the update related to this snapshot between the 2 >new demarcation messages. >> The drawback is that during this time, the BGP convergence is slow down >because "real time" BGP updates needs to wait for the end of this snapshot. >And this can be long (minutes, ten of minutes). Hence IMO, this is not >advisable for all (existing) Route Refresh. I would rather limit such >behavior to specific "on demand" request (e.g. through a new RR request su= b- >type) >> >> OTOH, if we just want to "refresh" the routes ("a"), i.e. know when to >purge the non-received one, we can interleave live BGP updates during the >refresh. This does not delay BGP convergence but we won't be able to detect >if there were inconsistencies and what they were. >> >> IMO, the draft would need to take a position between both options. >Eventually, it could be extended to cover both, if there is a desire for >this. >> If only "a" is needed, I'm not sure to see the value of the "begin" >demarcation message, as the sender of RR could locally mark its route when >sending the RR, rather than when receiving the "RR Start" >> >> Thank you, >> Bruno >> >> >__________________________________________________________________________= __ >_____________________________________________ >> >> 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 be= en >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 rraszuk@gmail.com Fri Oct 11 05:40:33 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05DEC11E8143 for ; Fri, 11 Oct 2013 05:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.342 X-Spam-Level: X-Spam-Status: No, score=-1.342 tagged_above=-999 required=5 tests=[AWL=0.636, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOMbA3Vs7JdJ for ; Fri, 11 Oct 2013 05:40:32 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 25BDF11E813D for ; Fri, 11 Oct 2013 05:40:31 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id aq17so6111578iec.20 for ; Fri, 11 Oct 2013 05:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=GPZMrXy72XEe9H1/RSihRVoLLhyZ7is6vNlktlgVTPU=; b=Sr92zF4JLdYxBFckyVNMycUfjxoFbIxPlpJExW7mgHMIdxhNiJVfFSOSTn5hFxIKXf mKwZISqB3uVrZg5glqn50VijzHQ/foOPW3PLoPjGrudzL1RAKGPb5aVWk1j4jGPwOYB8 ufbv6BNOmBglw1V35jS52WSvTk5aXLz9Jf7Y3y6Ap2NGu+dqDJlSxZXSQO0sePGBd9R3 MgT/ACpbndlcJZiYqJraYh7tHxgwxjQhALMysZBNeyI4yKd0UKojZh0apf5ZlMv26cDk ELKyW1cj6/MXIA2ZW1Odf9weRUWQchdGU08Wk8n+b6kQLnf2WG7SEECW8dkp7/Tv3dMr al8A== MIME-Version: 1.0 X-Received: by 10.51.16.3 with SMTP id fs3mr2476571igd.53.1381495231245; Fri, 11 Oct 2013 05:40:31 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.61.129 with HTTP; Fri, 11 Oct 2013 05:40:31 -0700 (PDT) In-Reply-To: <31600_1381479332_5257B3A4_31600_17759_1_53C29892C857584299CBF5D05346208A0706BB34@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <02b901ceb0b7$e1d74b90$a585e2b0$@ndzh.com> <25182_1380115164_5242E2DC_25182_16908_1_53C29892C857584299CBF5D05346208A0706195C@PEXCVZYM11.corporate.adroot.infra.ftgroup> <6777_1381409105_5256A151_6777_146_1_53C29892C857584299CBF5D05346208A0706B4BE@PEXCVZYM11.corporate.adroot.infra.ftgroup> <31600_1381479332_5257B3A4_31600_17759_1_53C29892C857584299CBF5D05346208A0706BB34@PEXCVZYM11.corporate.adroot.infra.ftgroup> Date: Fri, 11 Oct 2013 14:40:31 +0200 X-Google-Sender-Auth: iQWaIBXJf0HEPV9T-R1fN9UaQUA Message-ID: From: Robert Raszuk To: Bruno Decraene Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: idr wg Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 12:40:33 -0000 Hi Bruno, I understand your perspective, but one needs to keep in mind also BGP implementation side. Imagine BGP implementation which does not have a concept of per peer BGP_RIB_Out. So such implementation in order to be able to replay a frozen snapshot would need to queue incoming updates and withdraws to the global bgp table. That effectively means that one RR client requesting enhanced route refresh towards such RR will delay convergence of BGP to 1000 of other clients of the same RR which never needed route refresh. Is this what you would accept in your option "a" even if it would be a requirement ? Cheers, R. On Fri, Oct 11, 2013 at 10:15 AM, wrote: > Robert, > >>From: Robert Raszuk >Sent: Thursday, October 10, 2013 6:10 PM >> >>Hi Bruno, >> >>Let me observe that BGP Operation Message has been proposed to address >>"a" http://tools.ietf.org/html/draft-ietf-idr-operational-message-00 >> >>I would leave bgp enhanced route refresh to address "b" regardless how >>heavy weight it may sound .. IMHO it is required. > > Speaking of requirements, it would be good for the draft to document them= , in order for the WG to be able to understand the tradeoffs. > Current text is not specific enough: > - "The enhancement can be used to facilitate on-line, non-disruptive cons= istency validations of BGP routing updates." > - "It is sometimes necessary to perform routing consistency validations s= uch as checking for possible missing withdraws between BGP speakers" > > e.g.: > - is checking for missing updates or missing/incorrect attributes a requi= rement? > - is delaying routing convergence during all Route Refresh acceptable? As= a reminder, in BGP/MPLS environment, Route Refresh are pretty common and a= re typically automatically issued by a PE when a new VRF/VPN/RT is configur= ed. > > >From implementation point of view the demarcation point is only >>required at the receiver of the updates replay. The sender is free to >>send new updates during the replay the same way in regular route >>refresh as with enhanced route refresh .. I see no difference there at >>all. There is no need for any "snapshot" on the BGP speaker which >>replays the updates. > > What is needed or not depend on the requirements. Cf above point. > If you want to be able to "perform routing consistency validations" and d= etect a missed update, you need to exclude "new" updates during the route r= efresh process. Otherwise, the receiver won't be able to know whether this = new/unexpected update (i.e. not locally present when he received the RR STA= RT) is due to a missed one (i.e. you have detected an routing inconsistency= ) or a new normal one. > >>In fact the draft says the above in this sentence already giving an >>implementation hint: >> >> "When a route entry in the "ADJ-RIB-Out" changes, the advertisement of >> the modified route entry (instead of the snapshot entry) would suffic= e. > > Yes, and as a consequence, we this exclude the ability to detect missed u= pdate. > Also, given nothing is said about withdraw, I read that the sender is not= allowed to send live withdraw between RR start and RR stop, which delay th= e routing convergence by minutes. As a reminder, in BGP/MPLS environment, e= xplicit withdraw are required as implicit withdraw is not an option (with a= unique RD policy) and neither advertising the external interface in the IG= P. > > So to sum up, although I understand that trade-offs are required, the cur= rent text seems to get the drawbacks of both option a & b: > - delaying routing convergence by minutes during normal network operation= time (i.e. not only during troubleshooting) > - not allowing to detect missing updates and missing or incorrect attribu= tes > > So I'd like to see what the requirements were/are. At least, that does no= t seem to match mine. > > At the very minimum, the document needs to clearly spell out such limitat= ions. Because if it's difficult to troubleshoot where/why a BGP update has = been missed, it will probably be harder to troubleshoot where/why a BGP con= vergence has been delayed by minutes (harder because at troubleshooting tim= e, the problematic states have been erased). > > Thank you. > Bruno > >> >>Best, >>R. >> >> >> >> >> >>On Thu, Oct 10, 2013 at 2:45 PM, wrote: >>> Hi all, >>> >>> The draft may have two different goals: >>> -a- systematic but light checks for refreshing purpose >>> -b- "on demand" but extensive checks for troubleshooting/debugging purp= ose >>> >>> Because If we want to do a full check ("b"), i.e. determine which BGP >>routing information has not been reflected, we may need to define a real >>"snapshot" and only sends the update related to this snapshot between the= 2 >>new demarcation messages. >>> The drawback is that during this time, the BGP convergence is slow down >>because "real time" BGP updates needs to wait for the end of this snapsho= t. >>And this can be long (minutes, ten of minutes). Hence IMO, this is not >>advisable for all (existing) Route Refresh. I would rather limit such >>behavior to specific "on demand" request (e.g. through a new RR request s= ub- >>type) >>> >>> OTOH, if we just want to "refresh" the routes ("a"), i.e. know when to >>purge the non-received one, we can interleave live BGP updates during the >>refresh. This does not delay BGP convergence but we won't be able to dete= ct >>if there were inconsistencies and what they were. >>> >>> IMO, the draft would need to take a position between both options. >>Eventually, it could be extended to cover both, if there is a desire for >>this. >>> If only "a" is needed, I'm not sure to see the value of the "begin" >>demarcation message, as the sender of RR could locally mark its route whe= n >>sending the RR, rather than when receiving the "RR Start" >>> >>> Thank you, >>> Bruno >>> >>> >>_________________________________________________________________________= ___ >>_____________________________________________ >>> >>> 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 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 >>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 b= een >>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 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. > From bruno.decraene@orange.com Fri Oct 11 06:14:22 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA5E11E814C for ; Fri, 11 Oct 2013 06:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y029n-Ltswp6 for ; Fri, 11 Oct 2013 06:14:18 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 0423411E8151 for ; Fri, 11 Oct 2013 06:14:17 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 37C5E37462E; Fri, 11 Oct 2013 15:14:16 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id F1C0615807D; Fri, 11 Oct 2013 15:14:15 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Fri, 11 Oct 2013 15:14:15 +0200 From: To: Robert Raszuk Thread-Topic: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHOxn8ScsvnJwdZokqbyn8GN4d0RJnvdarQ Date: Fri, 11 Oct 2013 13:14:14 +0000 Message-ID: <30021_1381497256_5257F9A8_30021_10507_1_53C29892C857584299CBF5D05346208A0706BCE7@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <02b901ceb0b7$e1d74b90$a585e2b0$@ndzh.com> <25182_1380115164_5242E2DC_25182_16908_1_53C29892C857584299CBF5D05346208A0706195C@PEXCVZYM11.corporate.adroot.infra.ftgroup> <6777_1381409105_5256A151_6777_146_1_53C29892C857584299CBF5D05346208A0706B4BE@PEXCVZYM11.corporate.adroot.infra.ftgroup> <31600_1381479332_5257B3A4_31600_17759_1_53C29892C857584299CBF5D05346208A0706BB34@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.10.11.55414 Cc: idr wg Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 13:14:22 -0000 Hi Robert, >From: Robert Raszuk >Sent: Friday, October 11, 2013 2:41 PM > >Hi Bruno, > >I understand your perspective, but one needs to keep in mind also BGP >implementation side. Imagine BGP implementation which does not have a >concept of per peer BGP_RIB_Out. I was ready to keep silent (hidden?) the potential effect on peers, assumin= g that some people would say that this is "an implementation issue". However, your comment is very valid and I now believe that the draft should= also explicit the consequences of this new procedures on such peers. So many thanks for your comment. >So such implementation in order to be able to replay a frozen snapshot >would need to queue incoming updates and withdraws to the global bgp >table. I would suggest to defer further discussion on this point as there are too = much pending open questions and hence too many options to consider. So let'= s wait for answers from the authors or a revised version. >That effectively means that one RR client requesting enhanced route >refresh towards such RR will delay convergence of BGP to 1000 of other >clients of the same RR which never needed route refresh. Is this what >you would accept in your option "a" even if it would be a requirement >? >From a requirement perspective, I have precisely the opposite requirements = (i.e. do no delay BGP convergence in normal network operation time). >From a solution perspective, that's one of the concern I have regarding the= solution defined in this document. I'm waiting about clarification from th= e authors/document about the intended behavior is. Then we'll know what sid= e of the drawbacks we have to face and we'll be able to discuss whether we = can live with that or not (in the latter case a different solution or an ex= tension may be needed) Thank you. Cheers, Bruno > >Cheers, >R. > > > > > > > > > >On Fri, Oct 11, 2013 at 10:15 AM, wrote: >> Robert, >> >>>From: Robert Raszuk >Sent: Thursday, October 10, 2013 6:10 PM >>> >>>Hi Bruno, >>> >>>Let me observe that BGP Operation Message has been proposed to address >>>"a" http://tools.ietf.org/html/draft-ietf-idr-operational-message-00 >>> >>>I would leave bgp enhanced route refresh to address "b" regardless how >>>heavy weight it may sound .. IMHO it is required. >> >> Speaking of requirements, it would be good for the draft to document the= m, >in order for the WG to be able to understand the tradeoffs. >> Current text is not specific enough: >> - "The enhancement can be used to facilitate on-line, non-disruptive >consistency validations of BGP routing updates." >> - "It is sometimes necessary to perform routing consistency validations >such as checking for possible missing withdraws between BGP speakers" >> >> e.g.: >> - is checking for missing updates or missing/incorrect attributes a >requirement? >> - is delaying routing convergence during all Route Refresh acceptable? As >a reminder, in BGP/MPLS environment, Route Refresh are pretty common and a= re >typically automatically issued by a PE when a new VRF/VPN/RT is configured. >> >> >From implementation point of view the demarcation point is only >>>required at the receiver of the updates replay. The sender is free to >>>send new updates during the replay the same way in regular route >>>refresh as with enhanced route refresh .. I see no difference there at >>>all. There is no need for any "snapshot" on the BGP speaker which >>>replays the updates. >> >> What is needed or not depend on the requirements. Cf above point. >> If you want to be able to "perform routing consistency validations" and >detect a missed update, you need to exclude "new" updates during the route >refresh process. Otherwise, the receiver won't be able to know whether this >new/unexpected update (i.e. not locally present when he received the RR >START) is due to a missed one (i.e. you have detected an routing >inconsistency) or a new normal one. >> >>>In fact the draft says the above in this sentence already giving an >>>implementation hint: >>> >>> "When a route entry in the "ADJ-RIB-Out" changes, the advertisement of >>> the modified route entry (instead of the snapshot entry) would >suffice. >> >> Yes, and as a consequence, we this exclude the ability to detect missed >update. >> Also, given nothing is said about withdraw, I read that the sender is not >allowed to send live withdraw between RR start and RR stop, which delay the >routing convergence by minutes. As a reminder, in BGP/MPLS environment, >explicit withdraw are required as implicit withdraw is not an option (with= a >unique RD policy) and neither advertising the external interface in the IG= P. >> >> So to sum up, although I understand that trade-offs are required, the >current text seems to get the drawbacks of both option a & b: >> - delaying routing convergence by minutes during normal network operation >time (i.e. not only during troubleshooting) >> - not allowing to detect missing updates and missing or incorrect >attributes >> >> So I'd like to see what the requirements were/are. At least, that does n= ot >seem to match mine. >> >> At the very minimum, the document needs to clearly spell out such >limitations. Because if it's difficult to troubleshoot where/why a BGP >update has been missed, it will probably be harder to troubleshoot where/w= hy >a BGP convergence has been delayed by minutes (harder because at >troubleshooting time, the problematic states have been erased). >> >> Thank you. >> Bruno >> >>> >>>Best, >>>R. >>> >>> >>> >>> >>> >>>On Thu, Oct 10, 2013 at 2:45 PM, wrote: >>>> Hi all, >>>> >>>> The draft may have two different goals: >>>> -a- systematic but light checks for refreshing purpose >>>> -b- "on demand" but extensive checks for troubleshooting/debugging >purpose >>>> >>>> Because If we want to do a full check ("b"), i.e. determine which BGP >>>routing information has not been reflected, we may need to define a real >>>"snapshot" and only sends the update related to this snapshot between the >2 >>>new demarcation messages. >>>> The drawback is that during this time, the BGP convergence is slow down >>>because "real time" BGP updates needs to wait for the end of this >snapshot. >>>And this can be long (minutes, ten of minutes). Hence IMO, this is not >>>advisable for all (existing) Route Refresh. I would rather limit such >>>behavior to specific "on demand" request (e.g. through a new RR request >sub- >>>type) >>>> >>>> OTOH, if we just want to "refresh" the routes ("a"), i.e. know when to >>>purge the non-received one, we can interleave live BGP updates during the >>>refresh. This does not delay BGP convergence but we won't be able to >detect >>>if there were inconsistencies and what they were. >>>> >>>> IMO, the draft would need to take a position between both options. >>>Eventually, it could be extended to cover both, if there is a desire for >>>this. >>>> If only "a" is needed, I'm not sure to see the value of the "begin" >>>demarcation message, as the sender of RR could locally mark its route wh= en >>>sending the RR, rather than when receiving the "RR Start" >>>> >>>> Thank you, >>>> Bruno >>>> >>>> ___________________________________________________________________________= ______________________________________________ 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 rraszuk@gmail.com Fri Oct 11 06:34:19 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 961E621E8102 for ; Fri, 11 Oct 2013 06:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[AWL=0.477, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJa2MHmNJevn for ; Fri, 11 Oct 2013 06:34:18 -0700 (PDT) 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 8050A21E8100 for ; Fri, 11 Oct 2013 06:34:18 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id tp5so8485199ieb.0 for ; Fri, 11 Oct 2013 06:34:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=/Ur1tsr9w7+wxaK6XKmRdHZmzYm4HfznFxGGaELIg5I=; b=acVp64gMt8kXHA8o5k5h+h6zTfhjSjYBhiu7IaiUn2yrissh3/FDySSQOGhEpnhneh fWt0E3Z5wNOvNe4noQY8Xe6uDrEfW/glFVAk/dbw8GcMSRlEr1/N9omCqUzyOqjLUBNu ntpvxj5j6abN8Ek3RD89S+tTN5SZ6T43dU11SBD2/AjyNOI71OeoxpeMtMTT6mewffPM f+ApoHhEe2eplBEc5t1nD+HOki7R/8AAgCsrusgc2xi4zQDqUsg9rgeQcMH3n/Ly//zx wwAUokqsjXGQo5fdqm6aTBnpTvT3clKbtU/DS1KPyQ+0d7Mh0pSrA5JpCL1sdv5F1GkL tt7w== MIME-Version: 1.0 X-Received: by 10.50.27.9 with SMTP id p9mr2655245igg.53.1381498457491; Fri, 11 Oct 2013 06:34:17 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.61.129 with HTTP; Fri, 11 Oct 2013 06:34:17 -0700 (PDT) In-Reply-To: <30021_1381497256_5257F9A8_30021_10507_1_53C29892C857584299CBF5D05346208A0706BCE7@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <02b901ceb0b7$e1d74b90$a585e2b0$@ndzh.com> <25182_1380115164_5242E2DC_25182_16908_1_53C29892C857584299CBF5D05346208A0706195C@PEXCVZYM11.corporate.adroot.infra.ftgroup> <6777_1381409105_5256A151_6777_146_1_53C29892C857584299CBF5D05346208A0706B4BE@PEXCVZYM11.corporate.adroot.infra.ftgroup> <31600_1381479332_5257B3A4_31600_17759_1_53C29892C857584299CBF5D05346208A0706BB34@PEXCVZYM11.corporate.adroot.infra.ftgroup> <30021_1381497256_5257F9A8_30021_10507_1_53C29892C857584299CBF5D05346208A0706BCE7@PEXCVZYM11.corporate.adroot.infra.ftgroup> Date: Fri, 11 Oct 2013 15:34:17 +0200 X-Google-Sender-Auth: V3p3Qu0TJOg4PZiTtiUNEfadZxU Message-ID: From: Robert Raszuk To: Bruno Decraene Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: idr wg Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 13:34:19 -0000 Hi Bruno, I am not sure what questions are not answered. The proposed "feature" is shipping so it is very easy to test it in your own lab :) Moreover IDR has just recently accepted http://tools.ietf.org/html/draft-keyupate-idr-enhanced-refresh-impl-00 to be an IDR WG document so if you need additional questions answered in this document I think the best would be to propose those and allow implementations to answer in next revision. Also I think there is already third BGP implementation exaBGP which is open source which also supports this draft. Best, R. On Fri, Oct 11, 2013 at 3:14 PM, wrote: > Hi Robert, > >>From: Robert Raszuk >Sent: Friday, October 11, 2013 2:41 PM >> >>Hi Bruno, >> >>I understand your perspective, but one needs to keep in mind also BGP >>implementation side. Imagine BGP implementation which does not have a >>concept of per peer BGP_RIB_Out. > > I was ready to keep silent (hidden?) the potential effect on peers, assum= ing that some people would say that this is "an implementation issue". > > However, your comment is very valid and I now believe that the draft shou= ld also explicit the consequences of this new procedures on such peers. > So many thanks for your comment. > >>So such implementation in order to be able to replay a frozen snapshot >>would need to queue incoming updates and withdraws to the global bgp >>table. > > I would suggest to defer further discussion on this point as there are to= o much pending open questions and hence too many options to consider. So le= t's wait for answers from the authors or a revised version. > >>That effectively means that one RR client requesting enhanced route >>refresh towards such RR will delay convergence of BGP to 1000 of other >>clients of the same RR which never needed route refresh. Is this what >>you would accept in your option "a" even if it would be a requirement >>? > > From a requirement perspective, I have precisely the opposite requirement= s (i.e. do no delay BGP convergence in normal network operation time). > From a solution perspective, that's one of the concern I have regarding t= he solution defined in this document. I'm waiting about clarification from = the authors/document about the intended behavior is. Then we'll know what s= ide of the drawbacks we have to face and we'll be able to discuss whether w= e can live with that or not (in the latter case a different solution or an = extension may be needed) > > > Thank you. > Cheers, > Bruno > >> >>Cheers, >>R. >> >> >> >> >> >> >> >> >> >>On Fri, Oct 11, 2013 at 10:15 AM, wrote: >>> Robert, >>> >>>>From: Robert Raszuk >Sent: Thursday, October 10, 2013 6:10 PM >>>> >>>>Hi Bruno, >>>> >>>>Let me observe that BGP Operation Message has been proposed to address >>>>"a" http://tools.ietf.org/html/draft-ietf-idr-operational-message-00 >>>> >>>>I would leave bgp enhanced route refresh to address "b" regardless how >>>>heavy weight it may sound .. IMHO it is required. >>> >>> Speaking of requirements, it would be good for the draft to document th= em, >>in order for the WG to be able to understand the tradeoffs. >>> Current text is not specific enough: >>> - "The enhancement can be used to facilitate on-line, non-disruptive >>consistency validations of BGP routing updates." >>> - "It is sometimes necessary to perform routing consistency validations >>such as checking for possible missing withdraws between BGP speakers" >>> >>> e.g.: >>> - is checking for missing updates or missing/incorrect attributes a >>requirement? >>> - is delaying routing convergence during all Route Refresh acceptable? = As >>a reminder, in BGP/MPLS environment, Route Refresh are pretty common and = are >>typically automatically issued by a PE when a new VRF/VPN/RT is configure= d. >>> >>> >From implementation point of view the demarcation point is only >>>>required at the receiver of the updates replay. The sender is free to >>>>send new updates during the replay the same way in regular route >>>>refresh as with enhanced route refresh .. I see no difference there at >>>>all. There is no need for any "snapshot" on the BGP speaker which >>>>replays the updates. >>> >>> What is needed or not depend on the requirements. Cf above point. >>> If you want to be able to "perform routing consistency validations" and >>detect a missed update, you need to exclude "new" updates during the rout= e >>refresh process. Otherwise, the receiver won't be able to know whether th= is >>new/unexpected update (i.e. not locally present when he received the RR >>START) is due to a missed one (i.e. you have detected an routing >>inconsistency) or a new normal one. >>> >>>>In fact the draft says the above in this sentence already giving an >>>>implementation hint: >>>> >>>> "When a route entry in the "ADJ-RIB-Out" changes, the advertisement = of >>>> the modified route entry (instead of the snapshot entry) would >>suffice. >>> >>> Yes, and as a consequence, we this exclude the ability to detect missed >>update. >>> Also, given nothing is said about withdraw, I read that the sender is n= ot >>allowed to send live withdraw between RR start and RR stop, which delay t= he >>routing convergence by minutes. As a reminder, in BGP/MPLS environment, >>explicit withdraw are required as implicit withdraw is not an option (wit= h a >>unique RD policy) and neither advertising the external interface in the I= GP. >>> >>> So to sum up, although I understand that trade-offs are required, the >>current text seems to get the drawbacks of both option a & b: >>> - delaying routing convergence by minutes during normal network operati= on >>time (i.e. not only during troubleshooting) >>> - not allowing to detect missing updates and missing or incorrect >>attributes >>> >>> So I'd like to see what the requirements were/are. At least, that does = not >>seem to match mine. >>> >>> At the very minimum, the document needs to clearly spell out such >>limitations. Because if it's difficult to troubleshoot where/why a BGP >>update has been missed, it will probably be harder to troubleshoot where/= why >>a BGP convergence has been delayed by minutes (harder because at >>troubleshooting time, the problematic states have been erased). >>> >>> Thank you. >>> Bruno >>> >>>> >>>>Best, >>>>R. >>>> >>>> >>>> >>>> >>>> >>>>On Thu, Oct 10, 2013 at 2:45 PM, wrote: >>>>> Hi all, >>>>> >>>>> The draft may have two different goals: >>>>> -a- systematic but light checks for refreshing purpose >>>>> -b- "on demand" but extensive checks for troubleshooting/debugging >>purpose >>>>> >>>>> Because If we want to do a full check ("b"), i.e. determine which BGP >>>>routing information has not been reflected, we may need to define a rea= l >>>>"snapshot" and only sends the update related to this snapshot between t= he >>2 >>>>new demarcation messages. >>>>> The drawback is that during this time, the BGP convergence is slow do= wn >>>>because "real time" BGP updates needs to wait for the end of this >>snapshot. >>>>And this can be long (minutes, ten of minutes). Hence IMO, this is not >>>>advisable for all (existing) Route Refresh. I would rather limit such >>>>behavior to specific "on demand" request (e.g. through a new RR request >>sub- >>>>type) >>>>> >>>>> OTOH, if we just want to "refresh" the routes ("a"), i.e. know when t= o >>>>purge the non-received one, we can interleave live BGP updates during t= he >>>>refresh. This does not delay BGP convergence but we won't be able to >>detect >>>>if there were inconsistencies and what they were. >>>>> >>>>> IMO, the draft would need to take a position between both options. >>>>Eventually, it could be extended to cover both, if there is a desire fo= r >>>>this. >>>>> If only "a" is needed, I'm not sure to see the value of the "begin" >>>>demarcation message, as the sender of RR could locally mark its route w= hen >>>>sending the RR, rather than when receiving the "RR Start" >>>>> >>>>> Thank you, >>>>> Bruno >>>>> >>>>> > > _________________________________________________________________________= ________________________________________________ > > 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. > From thomas.mangin@exa-networks.co.uk Fri Oct 11 07:01:47 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0987511E81C3; Fri, 11 Oct 2013 07:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTgTpoY+4gyT; Fri, 11 Oct 2013 07:01:41 -0700 (PDT) Received: from out-9.mail.exa.net.uk (out-7.mail.exa.net.uk [82.219.4.135]) by ietfa.amsl.com (Postfix) with ESMTP id 73C7211E80E3; Fri, 11 Oct 2013 07:01:40 -0700 (PDT) Received: from smtp-3.mail.exa.net.uk (smtp-3.mail.exa.net.uk [82.219.5.3]) by out-9.mail.exa.net.uk (ExaSMTPD) with ESMTP id E38D6A00F6; Fri, 11 Oct 2013 15:01:37 +0100 (BST) Received: from [192.0.2.73] (office.exa-networks.co.uk [82.219.212.253]) (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 1BEC66C004E; Fri, 11 Oct 2013 15:01:37 +0100 (BST) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: multipart/signed; boundary="Apple-Mail=_E13F63C3-CF5D-4E57-A19C-E5CE868E50DF"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: Thomas Mangin In-Reply-To: Date: Fri, 11 Oct 2013 15:01:35 +0100 Message-Id: <3C8937E9-94D0-4646-9C62-89EB557B9805@exa-networks.co.uk> References: <02b901ceb0b7$e1d74b90$a585e2b0$@ndzh.com> <25182_1380115164_5242E2DC_25182_16908_1_53C29892C857584299CBF5D05346208A0706195C@PEXCVZYM11.corporate.adroot.infra.ftgroup> <6777_1381409105_5256A151_6777_146_1_53C29892C857584299CBF5D05346208A0706B4BE@PEXCVZYM11.corporate.adroot.infra.ftgroup> <31600_1381479332_5257B3A4_31600_17759_1_53C29892C857584299CBF5D05346208A0706BB34@PEXCVZYM11.corporate.adroot.infra.ftgroup> <30021_1381497256_5257F9A8_30021_10507_1_53C29892C857584299CBF5D05346208A0706BCE7@PEXCVZYM11.corporate.adroot.infra.ftgroup> To: idr-bounces@ietf.org X-Mailer: Apple Mail (2.1510) X-Virus-Scanned: clamav-milter 0.97.8 at out-2-2.mail.exa.net.uk X-Virus-Status: Clean Cc: Bruno Decraene , idr wg Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 14:01:47 -0000 --Apple-Mail=_E13F63C3-CF5D-4E57-A19C-E5CE868E50DF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello Bruno, Robert, ExaBGP does indeed implement the feature. I tested interoperability with = Cisco successfully - the feature is considered stable in 3.2.16 ( thank = you to Eric Rosen for providing me a way to test my code against Cisco's = implementation and Hideaki HAYASHI who was very helpful and helped me a = lot with behaviour correctness). The code buffers new announcements / withdrawals for the peer while the = Adj-RIB-OUT is being flushed. That said, I have no objection to change = the way the implementation should it to shown to be preferable. Thomas On 11 Oct 2013, at 14:34, Robert Raszuk wrote: > Hi Bruno, >=20 > I am not sure what questions are not answered. The proposed "feature" > is shipping so it is very easy to test it in your own lab :) >=20 > Moreover IDR has just recently accepted > http://tools.ietf.org/html/draft-keyupate-idr-enhanced-refresh-impl-00 > to be an IDR WG document so if you need additional questions answered > in this document I think the best would be to propose those and allow > implementations to answer in next revision. >=20 > Also I think there is already third BGP implementation exaBGP which is > open source which also supports this draft. >=20 > Best, > R. >=20 >=20 >=20 > On Fri, Oct 11, 2013 at 3:14 PM, wrote: >> Hi Robert, >>=20 >>> From: Robert Raszuk >Sent: Friday, October 11, 2013 2:41 PM >>>=20 >>> Hi Bruno, >>>=20 >>> I understand your perspective, but one needs to keep in mind also = BGP >>> implementation side. Imagine BGP implementation which does not have = a >>> concept of per peer BGP_RIB_Out. >>=20 >> I was ready to keep silent (hidden?) the potential effect on peers, = assuming that some people would say that this is "an implementation = issue". >>=20 >> However, your comment is very valid and I now believe that the draft = should also explicit the consequences of this new procedures on such = peers. >> So many thanks for your comment. >>=20 >>> So such implementation in order to be able to replay a frozen = snapshot >>> would need to queue incoming updates and withdraws to the global bgp >>> table. >>=20 >> I would suggest to defer further discussion on this point as there = are too much pending open questions and hence too many options to = consider. So let's wait for answers from the authors or a revised = version. >>=20 >>> That effectively means that one RR client requesting enhanced route >>> refresh towards such RR will delay convergence of BGP to 1000 of = other >>> clients of the same RR which never needed route refresh. Is this = what >>> you would accept in your option "a" even if it would be a = requirement >>> ? >>=20 >> =46rom a requirement perspective, I have precisely the opposite = requirements (i.e. do no delay BGP convergence in normal network = operation time). >> =46rom a solution perspective, that's one of the concern I have = regarding the solution defined in this document. I'm waiting about = clarification from the authors/document about the intended behavior is. = Then we'll know what side of the drawbacks we have to face and we'll be = able to discuss whether we can live with that or not (in the latter case = a different solution or an extension may be needed) >>=20 >>=20 >> Thank you. >> Cheers, >> Bruno >>=20 >>>=20 >>> Cheers, >>> R. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On Fri, Oct 11, 2013 at 10:15 AM, = wrote: >>>> Robert, >>>>=20 >>>>> From: Robert Raszuk >Sent: Thursday, October 10, 2013 6:10 PM >>>>>=20 >>>>> Hi Bruno, >>>>>=20 >>>>> Let me observe that BGP Operation Message has been proposed to = address >>>>> "a" = http://tools.ietf.org/html/draft-ietf-idr-operational-message-00 >>>>>=20 >>>>> I would leave bgp enhanced route refresh to address "b" regardless = how >>>>> heavy weight it may sound .. IMHO it is required. >>>>=20 >>>> Speaking of requirements, it would be good for the draft to = document them, >>> in order for the WG to be able to understand the tradeoffs. >>>> Current text is not specific enough: >>>> - "The enhancement can be used to facilitate on-line, = non-disruptive >>> consistency validations of BGP routing updates." >>>> - "It is sometimes necessary to perform routing consistency = validations >>> such as checking for possible missing withdraws between BGP = speakers" >>>>=20 >>>> e.g.: >>>> - is checking for missing updates or missing/incorrect attributes a >>> requirement? >>>> - is delaying routing convergence during all Route Refresh = acceptable? As >>> a reminder, in BGP/MPLS environment, Route Refresh are pretty common = and are >>> typically automatically issued by a PE when a new VRF/VPN/RT is = configured. >>>>=20 >>>>> =46rom implementation point of view the demarcation point is only >>>>> required at the receiver of the updates replay. The sender is free = to >>>>> send new updates during the replay the same way in regular route >>>>> refresh as with enhanced route refresh .. I see no difference = there at >>>>> all. There is no need for any "snapshot" on the BGP speaker which >>>>> replays the updates. >>>>=20 >>>> What is needed or not depend on the requirements. Cf above point. >>>> If you want to be able to "perform routing consistency validations" = and >>> detect a missed update, you need to exclude "new" updates during the = route >>> refresh process. Otherwise, the receiver won't be able to know = whether this >>> new/unexpected update (i.e. not locally present when he received the = RR >>> START) is due to a missed one (i.e. you have detected an routing >>> inconsistency) or a new normal one. >>>>=20 >>>>> In fact the draft says the above in this sentence already giving = an >>>>> implementation hint: >>>>>=20 >>>>> "When a route entry in the "ADJ-RIB-Out" changes, the = advertisement of >>>>> the modified route entry (instead of the snapshot entry) would >>> suffice. >>>>=20 >>>> Yes, and as a consequence, we this exclude the ability to detect = missed >>> update. >>>> Also, given nothing is said about withdraw, I read that the sender = is not >>> allowed to send live withdraw between RR start and RR stop, which = delay the >>> routing convergence by minutes. As a reminder, in BGP/MPLS = environment, >>> explicit withdraw are required as implicit withdraw is not an option = (with a >>> unique RD policy) and neither advertising the external interface in = the IGP. >>>>=20 >>>> So to sum up, although I understand that trade-offs are required, = the >>> current text seems to get the drawbacks of both option a & b: >>>> - delaying routing convergence by minutes during normal network = operation >>> time (i.e. not only during troubleshooting) >>>> - not allowing to detect missing updates and missing or incorrect >>> attributes >>>>=20 >>>> So I'd like to see what the requirements were/are. At least, that = does not >>> seem to match mine. >>>>=20 >>>> At the very minimum, the document needs to clearly spell out such >>> limitations. Because if it's difficult to troubleshoot where/why a = BGP >>> update has been missed, it will probably be harder to troubleshoot = where/why >>> a BGP convergence has been delayed by minutes (harder because at >>> troubleshooting time, the problematic states have been erased). >>>>=20 >>>> Thank you. >>>> Bruno >>>>=20 >>>>>=20 >>>>> Best, >>>>> R. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Thu, Oct 10, 2013 at 2:45 PM, = wrote: >>>>>> Hi all, >>>>>>=20 >>>>>> The draft may have two different goals: >>>>>> -a- systematic but light checks for refreshing purpose >>>>>> -b- "on demand" but extensive checks for = troubleshooting/debugging >>> purpose >>>>>>=20 >>>>>> Because If we want to do a full check ("b"), i.e. determine which = BGP >>>>> routing information has not been reflected, we may need to define = a real >>>>> "snapshot" and only sends the update related to this snapshot = between the >>> 2 >>>>> new demarcation messages. >>>>>> The drawback is that during this time, the BGP convergence is = slow down >>>>> because "real time" BGP updates needs to wait for the end of this >>> snapshot. >>>>> And this can be long (minutes, ten of minutes). Hence IMO, this is = not >>>>> advisable for all (existing) Route Refresh. I would rather limit = such >>>>> behavior to specific "on demand" request (e.g. through a new RR = request >>> sub- >>>>> type) >>>>>>=20 >>>>>> OTOH, if we just want to "refresh" the routes ("a"), i.e. know = when to >>>>> purge the non-received one, we can interleave live BGP updates = during the >>>>> refresh. This does not delay BGP convergence but we won't be able = to >>> detect >>>>> if there were inconsistencies and what they were. >>>>>>=20 >>>>>> IMO, the draft would need to take a position between both = options. >>>>> Eventually, it could be extended to cover both, if there is a = desire for >>>>> this. >>>>>> If only "a" is needed, I'm not sure to see the value of the = "begin" >>>>> demarcation message, as the sender of RR could locally mark its = route when >>>>> sending the RR, rather than when receiving the "RR Start" >>>>>>=20 >>>>>> Thank you, >>>>>> Bruno >>>>>>=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 >=20 --Apple-Mail=_E13F63C3-CF5D-4E57-A19C-E5CE868E50DF 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 iEYEARECAAYFAlJYBL8ACgkQA/52wvuLgaE5nQCcCz8O4D3PMTknlc2hjiwF9NYK rsAAoMoB+dFGyAD3NpkaEOXHRQ4XC7BE =z5d9 -----END PGP SIGNATURE----- --Apple-Mail=_E13F63C3-CF5D-4E57-A19C-E5CE868E50DF-- From bruno.decraene@orange.com Fri Oct 11 07:51:23 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4221321E81ED for ; Fri, 11 Oct 2013 07:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWaZxRhrCI5y for ; Fri, 11 Oct 2013 07:51:18 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 32BDA21E81E5 for ; Fri, 11 Oct 2013 07:51:07 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 840493B4055; Fri, 11 Oct 2013 16:51:05 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 691554C066; Fri, 11 Oct 2013 16:51:05 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Fri, 11 Oct 2013 16:51:05 +0200 From: To: Robert Raszuk Thread-Topic: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHOxoaVcsvnJwdZokqbyn8GN4d0RJnvi0rg Date: Fri, 11 Oct 2013 14:51:05 +0000 Message-ID: <22930_1381503065_52581059_22930_867_1_53C29892C857584299CBF5D05346208A0706BE10@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <02b901ceb0b7$e1d74b90$a585e2b0$@ndzh.com> <25182_1380115164_5242E2DC_25182_16908_1_53C29892C857584299CBF5D05346208A0706195C@PEXCVZYM11.corporate.adroot.infra.ftgroup> <6777_1381409105_5256A151_6777_146_1_53C29892C857584299CBF5D05346208A0706B4BE@PEXCVZYM11.corporate.adroot.infra.ftgroup> <31600_1381479332_5257B3A4_31600_17759_1_53C29892C857584299CBF5D05346208A0706BB34@PEXCVZYM11.corporate.adroot.infra.ftgroup> <30021_1381497256_5257F9A8_30021_10507_1_53C29892C857584299CBF5D05346208A0706BCE7@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.27.82422 Cc: idr wg Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 14:51:23 -0000 Hi Robert, >From: Robert Raszuk >Sent: Friday, October 11, 2013 3:34 PM > >Hi Bruno, > >I am not sure what questions are not answered.=20 Please refer to the questions in my previous emails on the IDR mailing list= (e.g. during WG last call) I don't recall any answer from the authors nor an updated document. Hence t= hey remained "not answered". >The proposed "feature" >is shipping so it is very easy to test it in your own lab :) I guess that this is a joke. But just in case, IMO, the behavior is defined as per the IETF spec, not as= per an implementation. (otherwise, the implementation would be always righ= t, bug free and interoperable from vendor A point of view... Idem from vend= or B point of view, even if they turned out to be non interoperable in lab = or worst in the network. And otherwise, there is no point in this IDR WG: l= et's just have vendor B write code and have other vendors reverse engineer = the spec) >Moreover IDR has just recently accepted >http://tools.ietf.org/html/draft-keyupate-idr-enhanced-refresh-impl-00 >to be an IDR WG document so if you need additional questions answered >in this document I think the best would be to propose those and allow >implementations to answer in next revision. My questions are related to the specification, not the implementation repor= t. But speaking about the implementation report, I'm wondering what was the ex= act TSS (Test Suite Structure), since some of my questions are related to i= nterop points which are not crystal clear in the spec. e.g. > 5) not receiving "Demarcation of the ending of a route refresh > How is the receiver supposed to react? > - Never ever send a new RR on this session? This would be problematic as = RR are typically used often, e.g. when a new VPN is configured. But it's no= t clear if sending a new RR is, strictly speaking, allowed by the current t= ext. Hence the receiver would take the risk of "upsetting" the speaker and = receiving a NOTIFICATION.=20 > - And if it sends a new RR, and receive a new "Demarcation of the beginni= ng of a route refresh", should it wait for two " Demarcation of the ending = of a route refresh" or is single one. (same question for the speaker: shoul= d it send two or one). So, was has been the result of the above test during the interop test? Best, Bruno >Also I think there is already third BGP implementation exaBGP which is >open source which also supports this draft. > >Best, >R. > > > >On Fri, Oct 11, 2013 at 3:14 PM, wrote: >> Hi Robert, >> >>>From: Robert Raszuk >Sent: Friday, October 11, 2013 2:41 PM >>> >>>Hi Bruno, >>> >>>I understand your perspective, but one needs to keep in mind also BGP >>>implementation side. Imagine BGP implementation which does not have a >>>concept of per peer BGP_RIB_Out. >> >> I was ready to keep silent (hidden?) the potential effect on peers, >assuming that some people would say that this is "an implementation issue". >> >> However, your comment is very valid and I now believe that the draft >should also explicit the consequences of this new procedures on such peers. >> So many thanks for your comment. >> >>>So such implementation in order to be able to replay a frozen snapshot >>>would need to queue incoming updates and withdraws to the global bgp >>>table. >> >> I would suggest to defer further discussion on this point as there are t= oo >much pending open questions and hence too many options to consider. So let= 's >wait for answers from the authors or a revised version. >> >>>That effectively means that one RR client requesting enhanced route >>>refresh towards such RR will delay convergence of BGP to 1000 of other >>>clients of the same RR which never needed route refresh. Is this what >>>you would accept in your option "a" even if it would be a requirement >>>? >> >> From a requirement perspective, I have precisely the opposite requiremen= ts >(i.e. do no delay BGP convergence in normal network operation time). >> From a solution perspective, that's one of the concern I have regarding >the solution defined in this document. I'm waiting about clarification from >the authors/document about the intended behavior is. Then we'll know what >side of the drawbacks we have to face and we'll be able to discuss whether >we can live with that or not (in the latter case a different solution or an >extension may be needed) >> >> >> Thank you. >> Cheers, >> Bruno >> >>> >>>Cheers, >>>R. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>On Fri, Oct 11, 2013 at 10:15 AM, wrote: >>>> Robert, >>>> >>>>>From: Robert Raszuk >Sent: Thursday, October 10, 2013 6:10 PM >>>>> >>>>>Hi Bruno, >>>>> >>>>>Let me observe that BGP Operation Message has been proposed to address >>>>>"a" http://tools.ietf.org/html/draft-ietf-idr-operational-message-00 >>>>> >>>>>I would leave bgp enhanced route refresh to address "b" regardless how >>>>>heavy weight it may sound .. IMHO it is required. >>>> >>>> Speaking of requirements, it would be good for the draft to document >them, >>>in order for the WG to be able to understand the tradeoffs. >>>> Current text is not specific enough: >>>> - "The enhancement can be used to facilitate on-line, non-disruptive >>>consistency validations of BGP routing updates." >>>> - "It is sometimes necessary to perform routing consistency validations >>>such as checking for possible missing withdraws between BGP speakers" >>>> >>>> e.g.: >>>> - is checking for missing updates or missing/incorrect attributes a >>>requirement? >>>> - is delaying routing convergence during all Route Refresh acceptable? >As >>>a reminder, in BGP/MPLS environment, Route Refresh are pretty common and >are >>>typically automatically issued by a PE when a new VRF/VPN/RT is >configured. >>>> >>>> >From implementation point of view the demarcation point is only >>>>>required at the receiver of the updates replay. The sender is free to >>>>>send new updates during the replay the same way in regular route >>>>>refresh as with enhanced route refresh .. I see no difference there at >>>>>all. There is no need for any "snapshot" on the BGP speaker which >>>>>replays the updates. >>>> >>>> What is needed or not depend on the requirements. Cf above point. >>>> If you want to be able to "perform routing consistency validations" and >>>detect a missed update, you need to exclude "new" updates during the rou= te >>>refresh process. Otherwise, the receiver won't be able to know whether >this >>>new/unexpected update (i.e. not locally present when he received the RR >>>START) is due to a missed one (i.e. you have detected an routing >>>inconsistency) or a new normal one. >>>> >>>>>In fact the draft says the above in this sentence already giving an >>>>>implementation hint: >>>>> >>>>> "When a route entry in the "ADJ-RIB-Out" changes, the advertisement >of >>>>> the modified route entry (instead of the snapshot entry) would >>>suffice. >>>> >>>> Yes, and as a consequence, we this exclude the ability to detect missed >>>update. >>>> Also, given nothing is said about withdraw, I read that the sender is >not >>>allowed to send live withdraw between RR start and RR stop, which delay >the >>>routing convergence by minutes. As a reminder, in BGP/MPLS environment, >>>explicit withdraw are required as implicit withdraw is not an option (wi= th >a >>>unique RD policy) and neither advertising the external interface in the >IGP. >>>> >>>> So to sum up, although I understand that trade-offs are required, the >>>current text seems to get the drawbacks of both option a & b: >>>> - delaying routing convergence by minutes during normal network >operation >>>time (i.e. not only during troubleshooting) >>>> - not allowing to detect missing updates and missing or incorrect >>>attributes >>>> >>>> So I'd like to see what the requirements were/are. At least, that does >not >>>seem to match mine. >>>> >>>> At the very minimum, the document needs to clearly spell out such >>>limitations. Because if it's difficult to troubleshoot where/why a BGP >>>update has been missed, it will probably be harder to troubleshoot >where/why >>>a BGP convergence has been delayed by minutes (harder because at >>>troubleshooting time, the problematic states have been erased). >>>> >>>> Thank you. >>>> Bruno >>>> >>>>> >>>>>Best, >>>>>R. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>On Thu, Oct 10, 2013 at 2:45 PM, wrote: >>>>>> Hi all, >>>>>> >>>>>> The draft may have two different goals: >>>>>> -a- systematic but light checks for refreshing purpose >>>>>> -b- "on demand" but extensive checks for troubleshooting/debugging >>>purpose >>>>>> >>>>>> Because If we want to do a full check ("b"), i.e. determine which BGP >>>>>routing information has not been reflected, we may need to define a re= al >>>>>"snapshot" and only sends the update related to this snapshot between >the >>>2 >>>>>new demarcation messages. >>>>>> The drawback is that during this time, the BGP convergence is slow >down >>>>>because "real time" BGP updates needs to wait for the end of this >>>snapshot. >>>>>And this can be long (minutes, ten of minutes). Hence IMO, this is not >>>>>advisable for all (existing) Route Refresh. I would rather limit such >>>>>behavior to specific "on demand" request (e.g. through a new RR request >>>sub- >>>>>type) >>>>>> >>>>>> OTOH, if we just want to "refresh" the routes ("a"), i.e. know when = to >>>>>purge the non-received one, we can interleave live BGP updates during >the >>>>>refresh. This does not delay BGP convergence but we won't be able to >>>detect >>>>>if there were inconsistencies and what they were. >>>>>> >>>>>> IMO, the draft would need to take a position between both options. >>>>>Eventually, it could be extended to cover both, if there is a desire f= or >>>>>this. >>>>>> If only "a" is needed, I'm not sure to see the value of the "begin" >>>>>demarcation message, as the sender of RR could locally mark its route >when >>>>>sending the RR, rather than when receiving the "RR Start" >>>>>> >>>>>> Thank you, >>>>>> Bruno >>>>>> >>>>>> >> >> >__________________________________________________________________________= __ >_____________________________________________ >> >> 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 be= en >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. From ju1738@att.com Fri Oct 11 08:23:59 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D7621E8128 for ; Fri, 11 Oct 2013 08:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id By9Dx0VW82oT for ; Fri, 11 Oct 2013 08:23:53 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 4174721E8114 for ; Fri, 11 Oct 2013 08:23:52 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 70818525.0.6788520.00-328.18884987.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 11 Oct 2013 15:23:52 +0000 (UTC) X-MXL-Hash: 5258180825ec9f93-e66f766fd1048f141c730f89996fb54536a75775 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 r9BFNoBC028041; Fri, 11 Oct 2013 11:23:51 -0400 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 r9BFNfXY027931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Oct 2013 11:23:45 -0400 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (MISOUT7MSGHUB9F.itservices.sbc.com [144.151.223.71]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Fri, 11 Oct 2013 15:23:21 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.0158.001; Fri, 11 Oct 2013 11:23:21 -0400 From: "UTTARO, JAMES" To: "bruno.decraene@orange.com" , Robert Raszuk Thread-Topic: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHOxdMycsvnJwdZokqbyn8GN4d0RJnvIJlQgACU84CAAAlrAP//4KGA Date: Fri, 11 Oct 2013 15:23:21 +0000 Message-ID: References: <02b901ceb0b7$e1d74b90$a585e2b0$@ndzh.com> <25182_1380115164_5242E2DC_25182_16908_1_53C29892C857584299CBF5D05346208A0706195C@PEXCVZYM11.corporate.adroot.infra.ftgroup> <6777_1381409105_5256A151_6777_146_1_53C29892C857584299CBF5D05346208A0706B4BE@PEXCVZYM11.corporate.adroot.infra.ftgroup> <31600_1381479332_5257B3A4_31600_17759_1_53C29892C857584299CBF5D05346208A0706BB34@PEXCVZYM11.corporate.adroot.infra.ftgroup> <30021_1381497256_5257F9A8_30021_10507_1_53C29892C857584299CBF5D05346208A0706BCE7@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <30021_1381497256_5257F9A8_30021_10507_1_53C29892C857584299CBF5D05346208A0706BCE7@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.245] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] X-AnalysisOut: [v=2.0 cv=IPW1/HTG c=1 sm=0 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=yKoewWPzswEA:10 a=1UlMeTy-pWMA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=eGX8BGq6sjQA:10 a=48vgC7mUAAAA:8 a=z9tbli-vAAAA:8] X-AnalysisOut: [ a=X9m7rZHVJzXA2SnWkWUA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA] X-AnalysisOut: [:10 a=oAXR_kdF8uMA:10 a=ONsOK-9gGVZfmNth:21 a=THa-dpN_GWJi] X-AnalysisOut: [vaCh:21] Cc: idr wg Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 15:23:59 -0000 Comments In-Line.. Jim Uttaro -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of bruno= .decraene@orange.com Sent: Friday, October 11, 2013 9:14 AM To: Robert Raszuk Cc: idr wg Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh Hi Robert, >From: Robert Raszuk >Sent: Friday, October 11, 2013 2:41 PM > >Hi Bruno, > >I understand your perspective, but one needs to keep in mind also BGP >implementation side. Imagine BGP implementation which does not have a >concept of per peer BGP_RIB_Out. I was ready to keep silent (hidden?) the potential effect on peers, assumin= g that some people would say that this is "an implementation issue". However, your comment is very valid and I now believe that the draft should= also explicit the consequences of this new procedures on such peers. So many thanks for your comment. >So such implementation in order to be able to replay a frozen snapshot >would need to queue incoming updates and withdraws to the global bgp >table. I would suggest to defer further discussion on this point as there are too = much pending open questions and hence too many options to consider. So let'= s wait for answers from the authors or a revised version. >That effectively means that one RR client requesting enhanced route >refresh towards such RR will delay convergence of BGP to 1000 of other >clients of the same RR which never needed route refresh. Is this what >you would accept in your option "a" even if it would be a requirement >? >From a requirement perspective, I have precisely the opposite requirements = (i.e. do no delay BGP convergence in normal network operation time). >From a solution perspective, that's one of the concern I have regarding the= solution defined in this document. I'm waiting about clarification from th= e authors/document about the intended behavior is. Then we'll know what sid= e of the drawbacks we have to face and we'll be able to discuss whether we = can live with that or not (in the latter case a different solution or an ex= tension may be needed) [Jim U>] Our customers expect the fastest convergence possible. In my netwo= rk I have taken steps to do this. May be good to get external customers to = weigh in on the reqs also.. Thank you. Cheers, Bruno > >Cheers, >R. > > > > > > > > > >On Fri, Oct 11, 2013 at 10:15 AM, wrote: >> Robert, >> >>>From: Robert Raszuk >Sent: Thursday, October 10, 2013 6:10 PM >>> >>>Hi Bruno, >>> >>>Let me observe that BGP Operation Message has been proposed to address >>>"a" http://tools.ietf.org/html/draft-ietf-idr-operational-message-00 >>> >>>I would leave bgp enhanced route refresh to address "b" regardless how >>>heavy weight it may sound .. IMHO it is required. >> >> Speaking of requirements, it would be good for the draft to document the= m, >in order for the WG to be able to understand the tradeoffs. >> Current text is not specific enough: >> - "The enhancement can be used to facilitate on-line, non-disruptive >consistency validations of BGP routing updates." >> - "It is sometimes necessary to perform routing consistency validations >such as checking for possible missing withdraws between BGP speakers" >> >> e.g.: >> - is checking for missing updates or missing/incorrect attributes a >requirement? >> - is delaying routing convergence during all Route Refresh acceptable? A= s >a reminder, in BGP/MPLS environment, Route Refresh are pretty common and a= re >typically automatically issued by a PE when a new VRF/VPN/RT is configured= . >> >> >From implementation point of view the demarcation point is only >>>required at the receiver of the updates replay. The sender is free to >>>send new updates during the replay the same way in regular route >>>refresh as with enhanced route refresh .. I see no difference there at >>>all. There is no need for any "snapshot" on the BGP speaker which >>>replays the updates. >> >> What is needed or not depend on the requirements. Cf above point. >> If you want to be able to "perform routing consistency validations" and >detect a missed update, you need to exclude "new" updates during the route >refresh process. Otherwise, the receiver won't be able to know whether thi= s >new/unexpected update (i.e. not locally present when he received the RR >START) is due to a missed one (i.e. you have detected an routing >inconsistency) or a new normal one. >> >>>In fact the draft says the above in this sentence already giving an >>>implementation hint: >>> >>> "When a route entry in the "ADJ-RIB-Out" changes, the advertisement o= f >>> the modified route entry (instead of the snapshot entry) would >suffice. >> >> Yes, and as a consequence, we this exclude the ability to detect missed >update. >> Also, given nothing is said about withdraw, I read that the sender is no= t >allowed to send live withdraw between RR start and RR stop, which delay th= e >routing convergence by minutes. As a reminder, in BGP/MPLS environment, >explicit withdraw are required as implicit withdraw is not an option (with= a >unique RD policy) and neither advertising the external interface in the IG= P. >> >> So to sum up, although I understand that trade-offs are required, the >current text seems to get the drawbacks of both option a & b: >> - delaying routing convergence by minutes during normal network operatio= n >time (i.e. not only during troubleshooting) >> - not allowing to detect missing updates and missing or incorrect >attributes >> >> So I'd like to see what the requirements were/are. At least, that does n= ot >seem to match mine. >> >> At the very minimum, the document needs to clearly spell out such >limitations. Because if it's difficult to troubleshoot where/why a BGP >update has been missed, it will probably be harder to troubleshoot where/w= hy >a BGP convergence has been delayed by minutes (harder because at >troubleshooting time, the problematic states have been erased). >> >> Thank you. >> Bruno >> >>> >>>Best, >>>R. >>> >>> >>> >>> >>> >>>On Thu, Oct 10, 2013 at 2:45 PM, wrote: >>>> Hi all, >>>> >>>> The draft may have two different goals: >>>> -a- systematic but light checks for refreshing purpose >>>> -b- "on demand" but extensive checks for troubleshooting/debugging >purpose >>>> >>>> Because If we want to do a full check ("b"), i.e. determine which BGP >>>routing information has not been reflected, we may need to define a real >>>"snapshot" and only sends the update related to this snapshot between th= e >2 >>>new demarcation messages. >>>> The drawback is that during this time, the BGP convergence is slow dow= n >>>because "real time" BGP updates needs to wait for the end of this >snapshot. >>>And this can be long (minutes, ten of minutes). Hence IMO, this is not >>>advisable for all (existing) Route Refresh. I would rather limit such >>>behavior to specific "on demand" request (e.g. through a new RR request >sub- >>>type) >>>> >>>> OTOH, if we just want to "refresh" the routes ("a"), i.e. know when to >>>purge the non-received one, we can interleave live BGP updates during th= e >>>refresh. This does not delay BGP convergence but we won't be able to >detect >>>if there were inconsistencies and what they were. >>>> >>>> IMO, the draft would need to take a position between both options. >>>Eventually, it could be extended to cover both, if there is a desire for >>>this. >>>> If only "a" is needed, I'm not sure to see the value of the "begin" >>>demarcation message, as the sender of RR could locally mark its route wh= en >>>sending the RR, rather than when receiving the "RR Start" >>>> >>>> Thank you, >>>> Bruno >>>> >>>> ___________________________________________________________________________= ______________________________________________ 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 From rraszuk@gmail.com Fri Oct 11 12:28:35 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFE811E812F for ; Fri, 11 Oct 2013 12:28:35 -0700 (PDT) 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=[AWL=0.382, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgUrsI2IQsEX for ; Fri, 11 Oct 2013 12:28:35 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id ED56E11E80E8 for ; Fri, 11 Oct 2013 12:28:34 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id x13so9582194ief.29 for ; Fri, 11 Oct 2013 12:28:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=1ufFp6VKQwsLkUKx1RzZ277ByKVhFvgbdXcgxeiVQh8=; b=bgCvhN+dmgJPxGhJN5QWUxzmjO8IgGIEgldx34ObHtv7yIxlJiyFDh189yhhxeB3OW lydERmTbAbaYmLoCuQTbZFIsUzGP2n1fRPBbPxZdgPwCLCt6fA2DniMqRS7PNZ2ZbiW3 vzgO+24lB5quoKYfxz+ZRqDI0GRft9C2Ci7W63kKknwmxqBpyuVsCwGOgtlHFK2uerpd QwH4CAVfc93A9FkKFA7DsEF27EAH9dS/ufU8cxgdY49P5ZVQJYJOa9bg3x/uFijP2DJX ks7KU8Y7ztBTIESzAefAkywsQIkpLF32/+iN4XIb7iy6Jze7uyyE4TJx0y6d0oj71+1Y iQCg== MIME-Version: 1.0 X-Received: by 10.50.97.35 with SMTP id dx3mr3964810igb.55.1381519714417; Fri, 11 Oct 2013 12:28:34 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.61.129 with HTTP; Fri, 11 Oct 2013 12:28:34 -0700 (PDT) In-Reply-To: References: <02b901ceb0b7$e1d74b90$a585e2b0$@ndzh.com> <25182_1380115164_5242E2DC_25182_16908_1_53C29892C857584299CBF5D05346208A0706195C@PEXCVZYM11.corporate.adroot.infra.ftgroup> <6777_1381409105_5256A151_6777_146_1_53C29892C857584299CBF5D05346208A0706B4BE@PEXCVZYM11.corporate.adroot.infra.ftgroup> <31600_1381479332_5257B3A4_31600_17759_1_53C29892C857584299CBF5D05346208A0706BB34@PEXCVZYM11.corporate.adroot.infra.ftgroup> <30021_1381497256_5257F9A8_30021_10507_1_53C29892C857584299CBF5D05346208A0706BCE7@PEXCVZYM11.corporate.adroot.infra.ftgroup> Date: Fri, 11 Oct 2013 21:28:34 +0200 X-Google-Sender-Auth: jTOqiHC757l4-v-KGyY4qrndqa4 Message-ID: From: Robert Raszuk To: "UTTARO, JAMES" Content-Type: text/plain; charset=ISO-8859-1 Cc: "bruno.decraene@orange.com" , idr wg Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 19:28:35 -0000 > [Jim U>] Our customers expect the fastest convergence possible. In my > network I have taken steps to do this. By recommending deployment of "BGP Persistence" ? Note that not so far back you have wrote in version -01 of "BGP Persistence" draft: The lack of convergence within a Layer 3 topology during the persistent state SHOULD be considered since it may adversely affect services, however, an assumption is made that a degraded service is preferable to a complete service outage during a large-scale BGP control plane failure. Best, R. From ju1738@att.com Fri Oct 11 12:34:43 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E19611E8174 for ; Fri, 11 Oct 2013 12:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGct66agvBp1 for ; Fri, 11 Oct 2013 12:34:24 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 5C48111E812F for ; Fri, 11 Oct 2013 12:34:24 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id fb258525.0.6953137.00-473.19358873.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 11 Oct 2013 19:34:24 +0000 (UTC) X-MXL-Hash: 525852c02a80f292-8925f6eaec65f27590d129760eae0526c4bee214 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 r9BJYMsB026771; Fri, 11 Oct 2013 15:34:23 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r9BJYHhv026676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Oct 2013 15:34:19 -0400 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (MISOUT7MSGHUB9F.itservices.sbc.com [144.151.223.71]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Fri, 11 Oct 2013 19:34:13 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.0158.001; Fri, 11 Oct 2013 15:34:12 -0400 From: "UTTARO, JAMES" To: Robert Raszuk Thread-Topic: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHOxdMycsvnJwdZokqbyn8GN4d0RJnvIJlQgACU84CAAAlrAP//4KGAgACH9gD//75VkA== Date: Fri, 11 Oct 2013 19:34:12 +0000 Message-ID: References: <02b901ceb0b7$e1d74b90$a585e2b0$@ndzh.com> <25182_1380115164_5242E2DC_25182_16908_1_53C29892C857584299CBF5D05346208A0706195C@PEXCVZYM11.corporate.adroot.infra.ftgroup> <6777_1381409105_5256A151_6777_146_1_53C29892C857584299CBF5D05346208A0706B4BE@PEXCVZYM11.corporate.adroot.infra.ftgroup> <31600_1381479332_5257B3A4_31600_17759_1_53C29892C857584299CBF5D05346208A0706BB34@PEXCVZYM11.corporate.adroot.infra.ftgroup> <30021_1381497256_5257F9A8_30021_10507_1_53C29892C857584299CBF5D05346208A0706BCE7@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.144.30] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] X-AnalysisOut: [v=2.0 cv=IPW1/HTG c=1 sm=0 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=gb2RCHN8JdgA:10 a=1UlMeTy-pWMA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=eGX8BGq6sjQA:10 a=pGLkceISAAAA:8 a=z9tbli-vAAAA:8] X-AnalysisOut: [ a=m2Lkamjyci59dbySam8A:9 a=CjuIK1q_8ugA:10 a=MSl-tDqOz04A] X-AnalysisOut: [:10 a=oAXR_kdF8uMA:10] Cc: "bruno.decraene@orange.com" , idr wg Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 19:34:43 -0000 And your point?=20 -----Original Message----- From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Rasz= uk Sent: Friday, October 11, 2013 3:29 PM To: UTTARO, JAMES Cc: bruno.decraene@orange.com; idr wg Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh > [Jim U>] Our customers expect the fastest convergence possible. In my > network I have taken steps to do this. By recommending deployment of "BGP Persistence" ? Note that not so far back you have wrote in version -01 of "BGP Persistence" draft: The lack of convergence within a Layer 3 topology during the persistent state SHOULD be considered since it may adversely affect services, however, an assumption is made that a degraded service is preferable to a complete service outage during a large-scale BGP control plane failure. Best, R. From keyupate@cisco.com Fri Oct 11 13:24:34 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9F9F21E814D for ; Fri, 11 Oct 2013 13:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78jSOgEYvaJC for ; Fri, 11 Oct 2013 13:24:24 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5DC21E8146 for ; Fri, 11 Oct 2013 13:24:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3240; q=dns/txt; s=iport; t=1381523050; x=1382732650; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=DvxOIyxY3j54pbVQRow6s662JMjmUFN/bt3HEmuHcpk=; b=mfZdNBDWaB2nAOIH3jV7b7k52I8nrIUJY1GnlOGDSAlbPCJmr9VvRG8Y yb+mEdnzaeTSIj0NorN81Q/eTCPrXJeSsxrb1TrwRbiZH7Zcuq0CkG4pM MHpXfurC2B8X66/G3PptnDE1GklKgNU8B4rfY0Tkmq7Go6RYrbzeXB0w6 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAHhdWFKtJV2a/2dsb2JhbABagwc4UsFZgSUWdIIlAQEBAwEBAQE3NAsSAQgYChQ3CyUCBAENBQiHeAYMu1cEjX0BC4ENMQeDH4EEA6oHgySBaQgXIg X-IronPort-AV: E=Sophos;i="4.93,1082,1378857600"; d="scan'208";a="270966368" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 11 Oct 2013 20:24:09 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9BKO96s012927 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Oct 2013 20:24:09 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.217]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Fri, 11 Oct 2013 15:24:08 -0500 From: "Keyur Patel (keyupate)" To: Robert Raszuk , Bruno Decraene Thread-Topic: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHOxbaKqDTLsKyCeka1DYxEyTqFhZnubsaAgAFj74A= Date: Fri, 11 Oct 2013 20:24:08 +0000 Message-ID: <4931A85EED76CA48BD52F2D94E7FAB0E0BB80405@xmb-aln-x09.cisco.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.2.130206 x-originating-ip: [10.33.12.38] Content-Type: text/plain; charset="us-ascii" Content-ID: <4902122751F05946ADDD35087EF14DE8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: idr wg Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 20:24:35 -0000 Bruno, Apologies for the delayed response. Comments are inlined #Keyur. > > > > >On Thu, Oct 10, 2013 at 2:45 PM, wrote: >> Hi all, >> >> The draft may have two different goals: >> -a- systematic but light checks for refreshing purpose >> -b- "on demand" but extensive checks for troubleshooting/debugging >>purpose #Keyur: Sure. >> >> Because If we want to do a full check ("b"), i.e. determine which BGP >>routing information has not been reflected, we may need to define a real >>"snapshot" and only sends the update related to this snapshot between >>the 2 new demarcation messages. >> The drawback is that during this time, the BGP convergence is slow down >>because "real time" BGP updates needs to wait for the end of this >>snapshot. #Keyur: I am not sure if I agree with the above comment. Why can't an implementation interleave routes (refresh with "real time updates")? >> And this can be long (minutes, ten of minutes). Hence IMO, this is not >>advisable for all (existing) Route Refresh. I would rather limit such >>behavior to specific "on demand" request (e.g. through a new RR request >>sub-type) #Keyur: Ack. Regards, Keyur >> >> OTOH, if we just want to "refresh" the routes ("a"), i.e. know when to >>purge the non-received one, we can interleave live BGP updates during >>the refresh. This does not delay BGP convergence but we won't be able to >>detect if there were inconsistencies and what they were. >> >> IMO, the draft would need to take a position between both options. >>Eventually, it could be extended to cover both, if there is a desire for >>this. >> If only "a" is needed, I'm not sure to see the value of the "begin" >>demarcation message, as the sender of RR could locally mark its route >>when sending the RR, rather than when receiving the "RR Start" >> >> Thank you, >> Bruno >> >>=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. >> >> 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 >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From keyupate@cisco.com Fri Oct 11 16:37:10 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 445DD11E819F for ; Fri, 11 Oct 2013 16:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OAmQgJT2R82Q for ; Fri, 11 Oct 2013 16:37:05 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 5A41511E8194 for ; Fri, 11 Oct 2013 16:37:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8805; q=dns/txt; s=iport; t=1381534621; x=1382744221; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=xFrTFN4eRpPRupmQNEO4HjGGWjyxuNo0r0xQsl41YG8=; b=d/2xXPbW0HwGUmHQ47eeLZanyXGqq/DV3NGQESzjbNn7wZK0C5EEoJa8 T9gbz+vcLZEdiPVWsoaChrxpT6qh5KHw47AwBa3tFtFAlP7bfNbTgJhDd iUR5DX3cSdwyvvDT5NnMCof+/6E3s8V0D/dKr4lowxQReqIJ2e866Ec/L I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIFALmKWFKtJXHA/2dsb2JhbABagwc4UsFegSIWdIIlAQEBBAEBATc0CxIBCBUBAgoUNwslAgQBDQUIh34MvA+OAwELgQ0xB4MfgQQDlCiFDJBTgySBZwEBBQIXBhw X-IronPort-AV: E=Sophos;i="4.93,479,1378857600"; d="scan'208";a="271210814" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 11 Oct 2013 23:37:00 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9BNb0Uc017194 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Oct 2013 23:37:00 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.217]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Fri, 11 Oct 2013 18:37:00 -0500 From: "Keyur Patel (keyupate)" To: "bruno.decraene@orange.com" , Robert Raszuk Thread-Topic: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHOxbaKqDTLsKyCeka1DYxEyTqFhZnubsaAgAENuICAAIwagA== Date: Fri, 11 Oct 2013 23:36:59 +0000 Message-ID: <4931A85EED76CA48BD52F2D94E7FAB0E0BB814B6@xmb-aln-x09.cisco.com> In-Reply-To: <31600_1381479332_5257B3A4_31600_17759_1_53C29892C857584299CBF5D05346208A0706BB34@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.33.12.38] Content-Type: text/plain; charset="us-ascii" Content-ID: <992F48BDF5A6664A8F592BC8E476A7AB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: idr wg Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 23:37:10 -0000 Hi Bruno, Comments inlined #Keyur On 10/11/13 1:15 AM, "bruno.decraene@orange.com" wrote: >Robert, > >>From: Robert Raszuk >Sent: Thursday, October 10, 2013 6:10 PM >> >>Hi Bruno, >> >>Let me observe that BGP Operation Message has been proposed to address >>"a" http://tools.ietf.org/html/draft-ietf-idr-operational-message-00 >> >>I would leave bgp enhanced route refresh to address "b" regardless how >>heavy weight it may sound .. IMHO it is required. > >Speaking of requirements, it would be good for the draft to document >them, in order for the WG to be able to understand the tradeoffs. >Current text is not specific enough: >- "The enhancement can be used to facilitate on-line, non-disruptive >consistency validations of BGP routing updates." >- "It is sometimes necessary to perform routing consistency validations >such as checking for possible missing withdraws between BGP speakers" #Keyur: IMHO, the draft tries to ensure that BGP tables exchanged between BGP peers are consistent. Furthermore, the mechanism described in the draft assists in identifying and fixing missing withdraws. Current Route Refresh mechanism does not achieve this functionality. The draft does NOT try to address missing prefix (reachability) announcements as they cannot be solved by Route Refresh mechanisms. Furthermore, in accordance with RFC4271 and RFC2918, the draft DOES NOT alter re-advertisement rules upon a receipt of a Route Refresh message. If you like, we can augment the draft text to reflect it. > >e.g.: >- is checking for missing updates or missing/incorrect attributes a >requirement? #Keyur: No (assuming you meant missing reachability updates). It does check for missing withdraws. >- is delaying routing convergence during all Route Refresh acceptable? As >a reminder, in BGP/MPLS environment, Route Refresh are pretty common and >are typically automatically issued by a PE when a new VRF/VPN/RT is >configured. #Keyur: No. I don't believe the draft tries to add any convergence delay. As I mentioned in my earlier email, there is no reason to not interleave updates (new or old). The rules mentioned in RFC2918 for re-advertisment of routes are not changed. Best Regards, Keyur >>From implementation point of view the demarcation point is only >>required at the receiver of the updates replay. The sender is free to >>send new updates during the replay the same way in regular route >>refresh as with enhanced route refresh .. I see no difference there at >>all. There is no need for any "snapshot" on the BGP speaker which >>replays the updates. > >What is needed or not depend on the requirements. Cf above point. >If you want to be able to "perform routing consistency validations" and >detect a missed update, you need to exclude "new" updates during the >route refresh process. Otherwise, the receiver won't be able to know >whether this new/unexpected update (i.e. not locally present when he >received the RR START) is due to a missed one (i.e. you have detected an >routing inconsistency) or a new normal one. > >>In fact the draft says the above in this sentence already giving an >>implementation hint: >> >> "When a route entry in the "ADJ-RIB-Out" changes, the advertisement of >> the modified route entry (instead of the snapshot entry) would >>suffice. > >Yes, and as a consequence, we this exclude the ability to detect missed >update. >Also, given nothing is said about withdraw, I read that the sender is not >allowed to send live withdraw between RR start and RR stop, which delay >the routing convergence by minutes. As a reminder, in BGP/MPLS >environment, explicit withdraw are required as implicit withdraw is not >an option (with a unique RD policy) and neither advertising the external >interface in the IGP. > >So to sum up, although I understand that trade-offs are required, the >current text seems to get the drawbacks of both option a & b: >- delaying routing convergence by minutes during normal network operation >time (i.e. not only during troubleshooting) >- not allowing to detect missing updates and missing or incorrect >attributes > >So I'd like to see what the requirements were/are. At least, that does >not seem to match mine. > >At the very minimum, the document needs to clearly spell out such >limitations. Because if it's difficult to troubleshoot where/why a BGP >update has been missed, it will probably be harder to troubleshoot >where/why a BGP convergence has been delayed by minutes (harder because >at troubleshooting time, the problematic states have been erased). > >Thank you. >Bruno > >> >>Best, >>R. >> >> >> >> >> >>On Thu, Oct 10, 2013 at 2:45 PM, wrote: >>> Hi all, >>> >>> The draft may have two different goals: >>> -a- systematic but light checks for refreshing purpose >>> -b- "on demand" but extensive checks for troubleshooting/debugging >>>purpose >>> >>> Because If we want to do a full check ("b"), i.e. determine which BGP >>routing information has not been reflected, we may need to define a real >>"snapshot" and only sends the update related to this snapshot between >>the 2 >>new demarcation messages. >>> The drawback is that during this time, the BGP convergence is slow down >>because "real time" BGP updates needs to wait for the end of this >>snapshot. >>And this can be long (minutes, ten of minutes). Hence IMO, this is not >>advisable for all (existing) Route Refresh. I would rather limit such >>behavior to specific "on demand" request (e.g. through a new RR request >>sub- >>type) >>> >>> OTOH, if we just want to "refresh" the routes ("a"), i.e. know when to >>purge the non-received one, we can interleave live BGP updates during the >>refresh. This does not delay BGP convergence but we won't be able to >>detect >>if there were inconsistencies and what they were. >>> >>> IMO, the draft would need to take a position between both options. >>Eventually, it could be extended to cover both, if there is a desire for >>this. >>> If only "a" is needed, I'm not sure to see the value of the "begin" >>demarcation message, as the sender of RR could locally mark its route >>when >>sending the RR, rather than when receiving the "RR Start" >>> >>> Thank you, >>> Bruno >>> >>> >>_________________________________________________________________________ >>___ >>_____________________________________________ >>> >>> 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 >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 From thomas.mangin@exa-networks.co.uk Sat Oct 12 04:34:22 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 088B221E816D; Sat, 12 Oct 2013 04:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnhF2MNhSUf6; Sat, 12 Oct 2013 04:34:15 -0700 (PDT) Received: from out-9.mail.exa.net.uk (out-7.mail.exa.net.uk [82.219.4.135]) by ietfa.amsl.com (Postfix) with ESMTP id B9F9D21E80F2; Sat, 12 Oct 2013 04:34:15 -0700 (PDT) Received: from smtp-3.mail.exa.net.uk (smtp-3.mail.exa.net.uk [82.219.5.3]) by out-9.mail.exa.net.uk (ExaSMTPD) with ESMTP id BA596A00ED; Sat, 12 Oct 2013 12:34:13 +0100 (BST) 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 878636C0047; Sat, 12 Oct 2013 12:34:13 +0100 (BST) References: <4931A85EED76CA48BD52F2D94E7FAB0E0BB814B6@xmb-aln-x09.cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <4931A85EED76CA48BD52F2D94E7FAB0E0BB814B6@xmb-aln-x09.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (11A501) From: Thomas Mangin Date: Sat, 12 Oct 2013 12:34:13 +0100 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: "bruno.decraene@orange.com" , Robert Raszuk , idr wg Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 11:34:22 -0000 > On 12 Oct 2013, at 00:36, "Keyur Patel \(keyupate\)" w= rote: >=20 > #Keyur: No. I don't believe the draft tries to add any convergence delay. > As I mentioned in my earlier email, there is no reason to not interleave > updates (new or old). The rules mentioned in RFC2918 for re-advertisment > of routes are not changed. It would be nice to be able to differentiate between re-emitted routes and n= ew routes. An attribute could be used for this purpose, tagging the new routes within t= he RR window, but I fear it would change the draft a lot / too much. Thomas= From heas@shrubbery.net Sun Oct 13 00:23:43 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB7121F9360; Sun, 13 Oct 2013 00:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwSPYbeptNyF; Sun, 13 Oct 2013 00:23:38 -0700 (PDT) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4206C11E818D; Sun, 13 Oct 2013 00:23:38 -0700 (PDT) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 476AA50A3; Sun, 13 Oct 2013 07:23:38 +0000 (UTC) Date: Sun, 13 Oct 2013 07:23:38 +0000 From: heasley To: Thomas Mangin Message-ID: <20131013072338.GB74525@shrubbery.net> References: <4931A85EED76CA48BD52F2D94E7FAB0E0BB814B6@xmb-aln-x09.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.5.21 (2010-09-15) Cc: idr wg , "idr-bounces@ietf.org" Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2013 07:23:43 -0000 Sat, Oct 12, 2013 at 12:34:13PM +0100, Thomas Mangin: > It would be nice to be able to differentiate between re-emitted routes and new routes. For what use(s)/reason(s)? > An attribute could be used for this purpose, tagging the new routes within the RR window, but I fear it would change the draft a lot / too much. From thomas.mangin@exa-networks.co.uk Sun Oct 13 05:10:20 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4577111E814D; Sun, 13 Oct 2013 05:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.25 X-Spam-Level: X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYoIjcFY6bs8; Sun, 13 Oct 2013 05:10:14 -0700 (PDT) Received: from out-9.mail.exa.net.uk (out-7.mail.exa.net.uk [82.219.4.135]) by ietfa.amsl.com (Postfix) with ESMTP id 78C5611E813F; Sun, 13 Oct 2013 05:10:09 -0700 (PDT) Received: from smtp-3.mail.exa.net.uk (smtp-3.mail.exa.net.uk [82.219.5.3]) by out-9.mail.exa.net.uk (ExaSMTPD) with ESMTP id 5846BA0052; Sun, 13 Oct 2013 13:10:08 +0100 (BST) Received: from ptr-34.212.219.82.rev.exa.net.uk (ptr-34.212.219.82.rev.exa.net.uk [82.219.212.34]) (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 1A6886C0047; Sun, 13 Oct 2013 13:10:08 +0100 (BST) Content-Type: multipart/signed; boundary="Apple-Mail=_D1DB4982-8E15-4349-BE89-B3936D46E68A"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Thomas Mangin In-Reply-To: <20131013072338.GB74525@shrubbery.net> Date: Sun, 13 Oct 2013 13:10:07 +0100 Message-Id: <40A136B6-737C-423E-B75F-E735D0430BE3@exa-networks.co.uk> References: <4931A85EED76CA48BD52F2D94E7FAB0E0BB814B6@xmb-aln-x09.cisco.com> <20131013072338.GB74525@shrubbery.net> To: heas@shrubbery.net X-Mailer: Apple Mail (2.1510) X-Virus-Scanned: clamav-milter 0.97.8 at out-2-2.mail.exa.net.uk X-Virus-Status: Clean Cc: idr wg , "idr-bounces@ietf.org" Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2013 12:10:20 -0000 --Apple-Mail=_D1DB4982-8E15-4349-BE89-B3936D46E68A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 13 Oct 2013, at 08:23, heasley wrote: > Sat, Oct 12, 2013 at 12:34:13PM +0100, Thomas Mangin: >> It would be nice to be able to differentiate between re-emitted = routes and new routes. >=20 > For what use(s)/reason(s)? Hello Heasley, Short answer: =20 As it would allow better snapshotting of the network state without = causing any delay in convergence, which may or may not be required when = debugging the network. If you are asking me when this would be advisable to what is in the = current draft, I can not answer as I have no use case in mind for the = feature myself. Long answer: The draft says that it wants to help to "perform routing consistency = validations". People on this list stated that any implementation = increasing convergence time are undesirable, therefore, new updates = should not be hold back while the RR process is taking place. In = practice this mean that during a RR refresh window, new and old updates = need to be interleaved to allow FIB update on the receiving router. In that case, the RR window is "non exclusive" and will have a mix of = old and current updates. NLRI changes could be made explicit by sending = first the previous NLRI and then the updated one, route withdrawal could = be made explicit the same way. However nothing allows to differentiate = new updates from "old" ones. It will not be possible to know if the NLRI = in an update was received during the RR window or was preceding it. Another consequence is that the synchronisation time will be defined by = the EoRR message and and not the BoRR. In the case of a snapshot, One can assume that the state of the updates = sent was calculated between the moment the RR request was sent and the = BoRR is received, which narrows the time to a small interval = (hopefully). In the case where new updates are sent during the RR window, the state = of the remote peer received is the state of the peer when the EoRR is = received and the route transfer is completed. The interval is therefore = more likely to be much longer and vary from peer to peer. Performing = check between several peer may then become more difficult if one is = trying to check the state of a whole IBGP mesh to make sure all the = announcements are consistent.=20 Having the updates containing the old (or new) routes tagged with a = attribute to differentiate them would allow to not delay any convergence = but still know what was the status of the peer at when the BoRR is = received. Depending on the problem being debugged, this may or may not be = important. =46rom the draft authors' point of view, it seems that no one = came back with a use case where this ambiguity is a problem. I am not advocating for any change to allow such feature, nothing = prevent the creation of a new draft which would including a new RR type = with this behaviour later on. Thomas --Apple-Mail=_D1DB4982-8E15-4349-BE89-B3936D46E68A 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 iEYEARECAAYFAlJajZ8ACgkQA/52wvuLgaEbfgCg4ej4W0UtimzNjmFCLIhAgA1R PiIAnRB7l3PG40ELXnWUPSHa5f/jmzte =DMVZ -----END PGP SIGNATURE----- --Apple-Mail=_D1DB4982-8E15-4349-BE89-B3936D46E68A-- From randy@psg.com Sun Oct 13 06:19:20 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE5821F9F9D; Sun, 13 Oct 2013 06:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAEJu46Em-Qm; Sun, 13 Oct 2013 06:19:20 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id DBD8E21F9E9A; Sun, 13 Oct 2013 06:19:16 -0700 (PDT) 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 1VVLZf-000618-Hg; Sun, 13 Oct 2013 13:19:12 +0000 Date: Sun, 13 Oct 2013 15:19:10 +0200 Message-ID: From: Randy Bush To: Thomas Mangin In-Reply-To: <40A136B6-737C-423E-B75F-E735D0430BE3@exa-networks.co.uk> References: <4931A85EED76CA48BD52F2D94E7FAB0E0BB814B6@xmb-aln-x09.cisco.com> <20131013072338.GB74525@shrubbery.net> <40A136B6-737C-423E-B75F-E735D0430BE3@exa-networks.co.uk> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: heas@shrubbery.net, idr wg , "idr-bounces@ietf.org" Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2013 13:19:20 -0000 > If you are asking me when this would be advisable to what is in the > current draft, I can not answer as I have no use case in mind for the > feature myself. QED From jakob.heitz@ericsson.com Sun Oct 13 08:25:06 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7BA111E81A3; Sun, 13 Oct 2013 08:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ur96scQodgiL; Sun, 13 Oct 2013 08:24:59 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 5D52E11E818E; Sun, 13 Oct 2013 08:24:48 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-e1-525abb3f2036 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 05.13.03458.F3BBA525; Sun, 13 Oct 2013 17:24:47 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0328.009; Sun, 13 Oct 2013 11:24:47 -0400 From: Jakob Heitz To: Thomas Mangin Thread-Topic: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHOxbapvhhox5K8NESLrKRViqHbe5nuXgKAgAENuYCAAQF0gIAAyGWAgAFMUQCAAFALgP//81Un Date: Sun, 13 Oct 2013 15:24:46 +0000 Message-ID: References: <4931A85EED76CA48BD52F2D94E7FAB0E0BB814B6@xmb-aln-x09.cisco.com> <20131013072338.GB74525@shrubbery.net>, <40A136B6-737C-423E-B75F-E735D0430BE3@exa-networks.co.uk> In-Reply-To: <40A136B6-737C-423E-B75F-E735D0430BE3@exa-networks.co.uk> 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+NgFrrILMWRmVeSWpSXmKPExsUyuXRPgq797qggg8s/9S1W31nLYjFn43RW i1e3nzFZTNq2mtWBxaP/7GYmjyVLfjJ5PGm9xRzAHMVlk5Kak1mWWqRvl8CV0Xn9IXvBOumK Ra9bmBsYn4h2MXJySAiYSHyau4cVwhaTuHBvPVsXIxeHkMBRRok1f8+zgCSEBJYzSrRPiwax 2QR0JL5d72IGsUWAmlvu7QerYRYolWi4dxMsLixgI7Hryxx2iBpbiWtLm5kg7CiJb83fwJax CKhK/FzUxghi8wrYS6zYMpUFYvFrRomvOzaBDeUUcJOYs28uG4jNCHTd91NrmCCWiUvcejKf CeJqAYkle84zQ9iiEi8f/2OFqNGRWLD7ExuErS2xbOFrZohlghInZz5hmcAoOgvJqFlIWmYh aZmFpGUBI8sqRo7S4tSy3HQjw02MwGg5JsHmuINxwSfLQ4zSHCxK4rxf3joHCQmkJ5akZqem FqQWxReV5qQWH2Jk4uCUamD0Xzl35kbbs2fjK9zjDm0S2Se4dG2l9fTb+reuqp9fsIP/+VfW osh1NX9agqzOpH6ef8711jeHlP9JVi0Zu//v379ljWPmit8Mb5PY3OsEPPkzbn+cteuouOPB dLv3Hiy+W/5teGbIJlQwWaotfs/Wc+nfH7Ws4OtadUj68YGp5XKFMWb6f1yKlViKMxINtZiL ihMBNAXvXGQCAAA= Cc: "heas@shrubbery.net" , idr wg , "idr-bounces@ietf.org" Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2013 15:25:06 -0000 You can't do snapshot. Not even "show bgp route" is a snapshot unless it's a really small router. The only way to get a snapshot is to coredump the bgp process and even then= , it's not a snapshot of what's in the FIB. -- Jakob Heitz. On Oct 13, 2013, at 5:10 AM, "Thomas Mangin" wrote: > On 13 Oct 2013, at 08:23, heasley wrote: >=20 >> Sat, Oct 12, 2013 at 12:34:13PM +0100, Thomas Mangin: >>> It would be nice to be able to differentiate between re-emitted routes = and new routes. >>=20 >> For what use(s)/reason(s)? >=20 >=20 > Hello Heasley, >=20 > Short answer: =20 >=20 > As it would allow better snapshotting of the network state without causin= g any delay in convergence, which may or may not be required when debugging= the network. > If you are asking me when this would be advisable to what is in the curre= nt draft, I can not answer as I have no use case in mind for the feature my= self. >=20 > Long answer: >=20 > The draft says that it wants to help to "perform routing consistency vali= dations". People on this list stated that any implementation increasing con= vergence time are undesirable, therefore, new updates should not be hold ba= ck while the RR process is taking place. In practice this mean that during = a RR refresh window, new and old updates need to be interleaved to allow FI= B update on the receiving router. >=20 > In that case, the RR window is "non exclusive" and will have a mix of old= and current updates. NLRI changes could be made explicit by sending first = the previous NLRI and then the updated one, route withdrawal could be made = explicit the same way. However nothing allows to differentiate new updates = from "old" ones. It will not be possible to know if the NLRI in an update w= as received during the RR window or was preceding it. >=20 > Another consequence is that the synchronisation time will be defined by t= he EoRR message and and not the BoRR. > In the case of a snapshot, One can assume that the state of the updates s= ent was calculated between the moment the RR request was sent and the BoRR = is received, which narrows the time to a small interval (hopefully). > In the case where new updates are sent during the RR window, the state of= the remote peer received is the state of the peer when the EoRR is receive= d and the route transfer is completed. The interval is therefore more like= ly to be much longer and vary from peer to peer. Performing check between s= everal peer may then become more difficult if one is trying to check the st= ate of a whole IBGP mesh to make sure all the announcements are consistent.= =20 >=20 > Having the updates containing the old (or new) routes tagged with a attri= bute to differentiate them would allow to not delay any convergence but sti= ll know what was the status of the peer at when the BoRR is received. >=20 > Depending on the problem being debugged, this may or may not be important= . From the draft authors' point of view, it seems that no one came back wit= h a use case where this ambiguity is a problem. >=20 > I am not advocating for any change to allow such feature, nothing prevent= the creation of a new draft which would including a new RR type with this = behaviour later on. >=20 > Thomas > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From thomas.mangin@exa-networks.co.uk Sun Oct 13 10:04:26 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F21B621E8105; Sun, 13 Oct 2013 10:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.668 X-Spam-Level: X-Spam-Status: No, score=-2.668 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxPzv9XW6Ga3; Sun, 13 Oct 2013 10:04:21 -0700 (PDT) Received: from out-9.mail.exa.net.uk (out-7.mail.exa.net.uk [82.219.4.135]) by ietfa.amsl.com (Postfix) with ESMTP id 4715921F92CD; Sun, 13 Oct 2013 10:03:52 -0700 (PDT) Received: from smtp-4.mail.exa.net.uk (smtp-4.mail.exa.net.uk [82.219.5.4]) by out-9.mail.exa.net.uk (ExaSMTPD) with ESMTP id 96206A0052; Sun, 13 Oct 2013 18:03:51 +0100 (BST) 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 925144006B; Sun, 13 Oct 2013 18:03:49 +0100 (BST) References: <4931A85EED76CA48BD52F2D94E7FAB0E0BB814B6@xmb-aln-x09.cisco.com> <20131013072338.GB74525@shrubbery.net> <40A136B6-737C-423E-B75F-E735D0430BE3@exa-networks.co.uk> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <32787A7F-896C-4858-ABF1-185E1D2CBECA@exa-networks.co.uk> X-Mailer: iPad Mail (11A501) From: Thomas Mangin Date: Sun, 13 Oct 2013 18:03:40 +0100 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: "heas@shrubbery.net" , idr wg , "idr-bounces@ietf.org" Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2013 17:04:26 -0000 Hello Jakob, You will need to help me understand why you consider that ExaBGP does not pe= rform a snapshot of the Adj-RIB-out with the current code. Are we not agreei= ng on the meaning of snapshot or is it something else ? Sincerely, Thomas Sent from my iPad > On 13 Oct 2013, at 16:24, Jakob Heitz wrote: >=20 > You can't do snapshot. >=20 > Not even "show bgp route" is a snapshot unless it's a really small router.= > The only way to get a snapshot is to coredump the bgp process and even the= n, it's not a snapshot of what's in the FIB. >=20 > -- > Jakob Heitz. >=20 >=20 >> On Oct 13, 2013, at 5:10 AM, "Thomas Mangin" wrote: >>=20 >>> On 13 Oct 2013, at 08:23, heasley wrote: >>>=20 >>> Sat, Oct 12, 2013 at 12:34:13PM +0100, Thomas Mangin: >>>> It would be nice to be able to differentiate between re-emitted routes a= nd new routes. >>>=20 >>> For what use(s)/reason(s)? >>=20 >>=20 >> Hello Heasley, >>=20 >> Short answer: =20 >>=20 >> As it would allow better snapshotting of the network state without causin= g any delay in convergence, which may or may not be required when debugging t= he network. >> If you are asking me when this would be advisable to what is in the curre= nt draft, I can not answer as I have no use case in mind for the feature mys= elf. >>=20 >> Long answer: >>=20 >> The draft says that it wants to help to "perform routing consistency vali= dations". People on this list stated that any implementation increasing conv= ergence time are undesirable, therefore, new updates should not be hold back= while the RR process is taking place. In practice this mean that during a R= R refresh window, new and old updates need to be interleaved to allow FIB up= date on the receiving router. >>=20 >> In that case, the RR window is "non exclusive" and will have a mix of old= and current updates. NLRI changes could be made explicit by sending first t= he previous NLRI and then the updated one, route withdrawal could be made ex= plicit the same way. However nothing allows to differentiate new updates fro= m "old" ones. It will not be possible to know if the NLRI in an update was r= eceived during the RR window or was preceding it. >>=20 >> Another consequence is that the synchronisation time will be defined by t= he EoRR message and and not the BoRR. >> In the case of a snapshot, One can assume that the state of the updates s= ent was calculated between the moment the RR request was sent and the BoRR i= s received, which narrows the time to a small interval (hopefully). >> In the case where new updates are sent during the RR window, the state of= the remote peer received is the state of the peer when the EoRR is received= and the route transfer is completed. The interval is therefore more likely= to be much longer and vary from peer to peer. Performing check between seve= ral peer may then become more difficult if one is trying to check the state o= f a whole IBGP mesh to make sure all the announcements are consistent.=20 >>=20 >> Having the updates containing the old (or new) routes tagged with a attri= bute to differentiate them would allow to not delay any convergence but stil= l know what was the status of the peer at when the BoRR is received. >>=20 >> Depending on the problem being debugged, this may or may not be important= . =46rom the draft authors' point of view, it seems that no one came back wi= th a use case where this ambiguity is a problem. >>=20 >> I am not advocating for any change to allow such feature, nothing prevent= the creation of a new draft which would including a new RR type with this b= ehaviour later on. >>=20 >> Thomas >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >=20 From jakob.heitz@ericsson.com Sun Oct 13 10:52:19 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D54A11E81B8; Sun, 13 Oct 2013 10:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ueTha3FjjlYp; Sun, 13 Oct 2013 10:51:57 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5147D21E80F4; Sun, 13 Oct 2013 10:51:43 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-93-525addaef6bc Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 87.45.09414.EADDA525; Sun, 13 Oct 2013 19:51:42 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0328.009; Sun, 13 Oct 2013 13:51:41 -0400 From: Jakob Heitz To: Thomas Mangin Thread-Topic: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHOxbapvhhox5K8NESLrKRViqHbe5nuXgKAgAENuYCAAQF0gIAAyGWAgAFMUQCAAFALgP//81UngABerwD//8peAA== Date: Sun, 13 Oct 2013 17:51:42 +0000 Message-ID: <9D3B9A0C-3BE6-4299-B22D-C759ABCEBD11@ericsson.com> References: <4931A85EED76CA48BD52F2D94E7FAB0E0BB814B6@xmb-aln-x09.cisco.com> <20131013072338.GB74525@shrubbery.net> <40A136B6-737C-423E-B75F-E735D0430BE3@exa-networks.co.uk> , <32787A7F-896C-4858-ABF1-185E1D2CBECA@exa-networks.co.uk> In-Reply-To: <32787A7F-896C-4858-ABF1-185E1D2CBECA@exa-networks.co.uk> 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+NgFrrALMWRmVeSWpSXmKPExsUyuXRPoO66u1FBBtfu6lqsvrOWxWLOxums Fq9uP2OymLRtNasDi0f/2c1MHkuW/GTyeNJ6izmAOYrLJiU1J7MstUjfLoEr4+y6t+wFbzQq tm5oZGtgPKfQxcjJISFgInGz9Q47hC0mceHeerYuRi4OIYGjjBKPX/5ghXCWM0q0n93NBFLF JqAj8e16FzOILQLU3XJvPwuIzSxQKtFw7yZYXFjARmLXlznsEDW2EteWNjNB2FkSN9+3gNWw CKhKHDt4DSzOK2Avcfz3HrC4kMBdJomGeeZdjBwcnAJuEocWF4OEGYGO+35qDRPEKnGJW0/m M0EcLSCxZM95ZghbVOLl43+sEDU6Egt2f2KDsLUlli18zQyxSlDi5MwnLBMYRWchGTULScss JC2zkLQsYGRZxchRWpxalptuZLCJERgrxyTYdHcw7nlpeYhRmoNFSZz3y1vnICGB9MSS1OzU 1ILUovii0pzU4kOMTBycUg2MW5hvLqwMlYsKUhFyuiYp4Wh4xlCpM2rdz/NRN25sLlkTJqfW cHzNrtZvy66E3hafuaYsWWPXxMMP3jeu+hpmahp9JDk70e6B0GmOi8f1Lm6IvpwjP/lqcPXr Zca8rv1O7MdOZoZ9z/W4/C1WuvK74N4rISKOqy5kS//v1Q9dnGrXV9BueNRYiaU4I9FQi7mo OBEAtfSoIGMCAAA= Cc: "heas@shrubbery.net" , idr wg , "idr-bounces@ietf.org" Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2013 17:52:19 -0000 I think I see what you want: Create a snapshot of an adj-rib-out at the "Demarcation of the beginning of= a route refresh" at the sending router and have the receiving router creat= e a similar snapshot of the corresponding adj-rib-in when it receives that = demarcation. This can be potentially expensive if lots of change is happening. It is wor= se on the receiving router, because it has no control of when it must creat= e the snapshot. Worse, it may need to do it for several incoming snapshots = from different neighbors. To deal with this, we must invent messages and pr= ocedures to abort the snapshot. I think this is a lot harder than enhanced-= route-refresh and deserves a separate draft and capability if we want to do= it. I would suggest a two step procedure: first, send a hash of the snapshot in= a single message and then send a real snapshot if the hash doesn't match a= t the receiving router. That way, you could send cheap hashes frequently an= d only send the expensive snapshot if an error was detected. Is there wider interest in this? -- Jakob Heitz. On Oct 13, 2013, at 10:03 AM, "Thomas Mangin" wrote: > Hello Jakob, >=20 > You will need to help me understand why you consider that ExaBGP does not= perform a snapshot of the Adj-RIB-out with the current code. Are we not ag= reeing on the meaning of snapshot or is it something else ? >=20 > Sincerely, >=20 > Thomas >=20 > Sent from my iPad >=20 >> On 13 Oct 2013, at 16:24, Jakob Heitz wrote: >>=20 >> You can't do snapshot. >>=20 >> Not even "show bgp route" is a snapshot unless it's a really small route= r. >> The only way to get a snapshot is to coredump the bgp process and even t= hen, it's not a snapshot of what's in the FIB. >>=20 >> -- >> Jakob Heitz. >>=20 >>=20 >>> On Oct 13, 2013, at 5:10 AM, "Thomas Mangin" wrote: >>>=20 >>>> On 13 Oct 2013, at 08:23, heasley wrote: >>>>=20 >>>> Sat, Oct 12, 2013 at 12:34:13PM +0100, Thomas Mangin: >>>>> It would be nice to be able to differentiate between re-emitted route= s and new routes. >>>>=20 >>>> For what use(s)/reason(s)? >>>=20 >>>=20 >>> Hello Heasley, >>>=20 >>> Short answer: =20 >>>=20 >>> As it would allow better snapshotting of the network state without caus= ing any delay in convergence, which may or may not be required when debuggi= ng the network. >>> If you are asking me when this would be advisable to what is in the cur= rent draft, I can not answer as I have no use case in mind for the feature = myself. >>>=20 >>> Long answer: >>>=20 >>> The draft says that it wants to help to "perform routing consistency va= lidations". People on this list stated that any implementation increasing c= onvergence time are undesirable, therefore, new updates should not be hold = back while the RR process is taking place. In practice this mean that durin= g a RR refresh window, new and old updates need to be interleaved to allow = FIB update on the receiving router. >>>=20 >>> In that case, the RR window is "non exclusive" and will have a mix of o= ld and current updates. NLRI changes could be made explicit by sending firs= t the previous NLRI and then the updated one, route withdrawal could be mad= e explicit the same way. However nothing allows to differentiate new update= s from "old" ones. It will not be possible to know if the NLRI in an update= was received during the RR window or was preceding it. >>>=20 >>> Another consequence is that the synchronisation time will be defined by= the EoRR message and and not the BoRR. >>> In the case of a snapshot, One can assume that the state of the updates= sent was calculated between the moment the RR request was sent and the BoR= R is received, which narrows the time to a small interval (hopefully). >>> In the case where new updates are sent during the RR window, the state = of the remote peer received is the state of the peer when the EoRR is recei= ved and the route transfer is completed. The interval is therefore more li= kely to be much longer and vary from peer to peer. Performing check between= several peer may then become more difficult if one is trying to check the = state of a whole IBGP mesh to make sure all the announcements are consisten= t.=20 >>>=20 >>> Having the updates containing the old (or new) routes tagged with a att= ribute to differentiate them would allow to not delay any convergence but s= till know what was the status of the peer at when the BoRR is received. >>>=20 >>> Depending on the problem being debugged, this may or may not be importa= nt. From the draft authors' point of view, it seems that no one came back w= ith a use case where this ambiguity is a problem. >>>=20 >>> I am not advocating for any change to allow such feature, nothing preve= nt the creation of a new draft which would including a new RR type with thi= s behaviour later on. >>>=20 >>> Thomas >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr >>=20 From thomas.mangin@exa-networks.co.uk Sun Oct 13 12:31:50 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C9421E811F; Sun, 13 Oct 2013 12:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILMiFgyUK31e; Sun, 13 Oct 2013 12:31:45 -0700 (PDT) Received: from out-9.mail.exa.net.uk (out-7.mail.exa.net.uk [82.219.4.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0966E21E8121; Sun, 13 Oct 2013 12:31:41 -0700 (PDT) Received: from smtp-3.mail.exa.net.uk (smtp-3.mail.exa.net.uk [82.219.5.3]) by out-9.mail.exa.net.uk (ExaSMTPD) with ESMTP id AE463A0053; Sun, 13 Oct 2013 20:31:40 +0100 (BST) 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 7D4646C0047; Sun, 13 Oct 2013 20:31:40 +0100 (BST) References: <4931A85EED76CA48BD52F2D94E7FAB0E0BB814B6@xmb-aln-x09.cisco.com> <20131013072338.GB74525@shrubbery.net> <40A136B6-737C-423E-B75F-E735D0430BE3@exa-networks.co.uk> <32787A7F-896C-4858-ABF1-185E1D2CBECA@exa-networks.co.uk> <9D3B9A0C-3BE6-4299-B22D-C759ABCEBD11@ericsson.com> Mime-Version: 1.0 (1.0) In-Reply-To: <9D3B9A0C-3BE6-4299-B22D-C759ABCEBD11@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (11A501) From: Thomas Mangin Date: Sun, 13 Oct 2013 20:31:38 +0100 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: "heas@shrubbery.net" , idr wg , "idr-bounces@ietf.org" Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2013 19:31:50 -0000 Jakob, I will have to admit that it is more than I had in mind :) As I have no use for the feature myself - I just implemented it and my users= are more likely to request a RR than have ExaBGP respond to one - I would r= ather hear from potential users about the problem they are trying to solve b= efore trying to solve an non-issue. My comment was more to highlight the current limitation(s) of the draft, wit= h a throw away idea of attribute, so it could be established if the trade of= f were acceptable or warrant more work on the document. For the moment, it is clear that more can be done to improve the feature but= it is not clear at all that if it should be .. QED ? Thomas Sent from my iPad > On 13 Oct 2013, at 18:51, Jakob Heitz wrote: >=20 > I think I see what you want: > Create a snapshot of an adj-rib-out at the "Demarcation of the beginning o= f a route refresh" at the sending router and have the receiving router creat= e a similar snapshot of the corresponding adj-rib-in when it receives that d= emarcation. >=20 > This can be potentially expensive if lots of change is happening. It is wo= rse on the receiving router, because it has no control of when it must creat= e the snapshot. Worse, it may need to do it for several incoming snapshots f= rom different neighbors. To deal with this, we must invent messages and proc= edures to abort the snapshot. I think this is a lot harder than enhanced-rou= te-refresh and deserves a separate draft and capability if we want to do it.= >=20 > I would suggest a two step procedure: first, send a hash of the snapshot i= n a single message and then send a real snapshot if the hash doesn't match a= t the receiving router. That way, you could send cheap hashes frequently and= only send the expensive snapshot if an error was detected. >=20 > Is there wider interest in this? >=20 > -- > Jakob Heitz. >=20 >=20 >> On Oct 13, 2013, at 10:03 AM, "Thomas Mangin" wrote: >>=20 >> Hello Jakob, >>=20 >> You will need to help me understand why you consider that ExaBGP does not= perform a snapshot of the Adj-RIB-out with the current code. Are we not agr= eeing on the meaning of snapshot or is it something else ? >>=20 >> Sincerely, >>=20 >> Thomas >>=20 >> Sent from my iPad >>=20 >>> On 13 Oct 2013, at 16:24, Jakob Heitz wrote: >>>=20 >>> You can't do snapshot. >>>=20 >>> Not even "show bgp route" is a snapshot unless it's a really small route= r. >>> The only way to get a snapshot is to coredump the bgp process and even t= hen, it's not a snapshot of what's in the FIB. >>>=20 >>> -- >>> Jakob Heitz. >>>=20 >>>=20 >>>>> On Oct 13, 2013, at 5:10 AM, "Thomas Mangin" wrote: >>>>>=20 >>>>> On 13 Oct 2013, at 08:23, heasley wrote: >>>>>=20 >>>>> Sat, Oct 12, 2013 at 12:34:13PM +0100, Thomas Mangin: >>>>>> It would be nice to be able to differentiate between re-emitted route= s and new routes. >>>>>=20 >>>>> For what use(s)/reason(s)? >>>>=20 >>>>=20 >>>> Hello Heasley, >>>>=20 >>>> Short answer: =20 >>>>=20 >>>> As it would allow better snapshotting of the network state without caus= ing any delay in convergence, which may or may not be required when debuggin= g the network. >>>> If you are asking me when this would be advisable to what is in the cur= rent draft, I can not answer as I have no use case in mind for the feature m= yself. >>>>=20 >>>> Long answer: >>>>=20 >>>> The draft says that it wants to help to "perform routing consistency va= lidations". People on this list stated that any implementation increasing co= nvergence time are undesirable, therefore, new updates should not be hold ba= ck while the RR process is taking place. In practice this mean that during a= RR refresh window, new and old updates need to be interleaved to allow FIB u= pdate on the receiving router. >>>>=20 >>>> In that case, the RR window is "non exclusive" and will have a mix of o= ld and current updates. NLRI changes could be made explicit by sending first= the previous NLRI and then the updated one, route withdrawal could be made e= xplicit the same way. However nothing allows to differentiate new updates fr= om "old" ones. It will not be possible to know if the NLRI in an update was r= eceived during the RR window or was preceding it. >>>>=20 >>>> Another consequence is that the synchronisation time will be defined by= the EoRR message and and not the BoRR. >>>> In the case of a snapshot, One can assume that the state of the updates= sent was calculated between the moment the RR request was sent and the BoRR= is received, which narrows the time to a small interval (hopefully). >>>> In the case where new updates are sent during the RR window, the state o= f the remote peer received is the state of the peer when the EoRR is receive= d and the route transfer is completed. The interval is therefore more likel= y to be much longer and vary from peer to peer. Performing check between sev= eral peer may then become more difficult if one is trying to check the state= of a whole IBGP mesh to make sure all the announcements are consistent.=20 >>>>=20 >>>> Having the updates containing the old (or new) routes tagged with a att= ribute to differentiate them would allow to not delay any convergence but st= ill know what was the status of the peer at when the BoRR is received. >>>>=20 >>>> Depending on the problem being debugged, this may or may not be importa= nt. =46rom the draft authors' point of view, it seems that no one came back w= ith a use case where this ambiguity is a problem. >>>>=20 >>>> I am not advocating for any change to allow such feature, nothing preve= nt the creation of a new draft which would including a new RR type with this= behaviour later on. >>>>=20 >>>> Thomas >>>> _______________________________________________ >>>> Idr mailing list >>>> Idr@ietf.org >>>> https://www.ietf.org/mailman/listinfo/idr >=20 From rraszuk@gmail.com Sun Oct 13 12:44:47 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA9ED11E814E for ; Sun, 13 Oct 2013 12:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.446 X-Spam-Level: X-Spam-Status: No, score=-1.446 tagged_above=-999 required=5 tests=[AWL=0.532, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FuqtEUOh1UzZ for ; Sun, 13 Oct 2013 12:44:47 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id B8F4321E8129 for ; Sun, 13 Oct 2013 12:44:44 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id ar20so1965309iec.12 for ; Sun, 13 Oct 2013 12:44:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=okPkcwDkxZgakYBLFYwtEa5kA8c0eqDGXJ+dvkHz+yE=; b=gZvGTjHIXRFPYiRNwE4SVppYX+dvLPe96NJeH7kISTw6WYFbSbnMJ8egl++4cXKFfj qaFq4l7B1bkV6FOcItW1yLnoVbBsq22HnlQecJqzd4R2vlRRvVSYt/0w09jwPwPQTSFn iX/ssC615qoObAaEuLER6Km0R5MweRhTXcVIXmvfkJQ5knetiy0GvDGg0OR88mBA/t3c ddykT0j3XYm6M3G+wFyH0xpUeIevihBIu6Mg+ullVP8EeAI+QjgvZfyauA1VIeaoSdHU bgMiGOd29oH0KJMhRu91IO9UcAHkghrcWbCkwGHehUyFS7CEpixA83dHgcfYi9mDHtc7 OPvA== MIME-Version: 1.0 X-Received: by 10.50.27.9 with SMTP id p9mr10293179igg.53.1381693484183; Sun, 13 Oct 2013 12:44:44 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.61.129 with HTTP; Sun, 13 Oct 2013 12:44:43 -0700 (PDT) In-Reply-To: References: <4931A85EED76CA48BD52F2D94E7FAB0E0BB814B6@xmb-aln-x09.cisco.com> <20131013072338.GB74525@shrubbery.net> <40A136B6-737C-423E-B75F-E735D0430BE3@exa-networks.co.uk> <32787A7F-896C-4858-ABF1-185E1D2CBECA@exa-networks.co.uk> <9D3B9A0C-3BE6-4299-B22D-C759ABCEBD11@ericsson.com> Date: Sun, 13 Oct 2013 21:44:43 +0200 X-Google-Sender-Auth: 0iZnXGUjzD0StE3ILF7K9k3UGFM Message-ID: From: Robert Raszuk To: Thomas Mangin Content-Type: text/plain; charset=ISO-8859-1 Cc: idr wg Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2013 19:44:48 -0000 > QED ? quod erat demonstrandum SRC: http://en.wikipedia.org/wiki/Q.E.D. ;-) Cheers, R. From thomas.mangin@exa-networks.co.uk Sun Oct 13 12:55:24 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE9E511E814E for ; Sun, 13 Oct 2013 12:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXXMe7hyk183 for ; Sun, 13 Oct 2013 12:55:19 -0700 (PDT) Received: from out-9.mail.exa.net.uk (out-7.mail.exa.net.uk [82.219.4.135]) by ietfa.amsl.com (Postfix) with ESMTP id 66A5411E8143 for ; Sun, 13 Oct 2013 12:55:19 -0700 (PDT) Received: from smtp-3.mail.exa.net.uk (smtp-3.mail.exa.net.uk [82.219.5.3]) by out-9.mail.exa.net.uk (ExaSMTPD) with ESMTP id 965F0A004C; Sun, 13 Oct 2013 20:55:18 +0100 (BST) 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 727706C0047; Sun, 13 Oct 2013 20:55:18 +0100 (BST) References: <4931A85EED76CA48BD52F2D94E7FAB0E0BB814B6@xmb-aln-x09.cisco.com> <20131013072338.GB74525@shrubbery.net> <40A136B6-737C-423E-B75F-E735D0430BE3@exa-networks.co.uk> <32787A7F-896C-4858-ABF1-185E1D2CBECA@exa-networks.co.uk> <9D3B9A0C-3BE6-4299-B22D-C759ABCEBD11@ericsson.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <5612945F-624F-4725-AA95-8D98CA871663@exa-networks.co.uk> X-Mailer: iPad Mail (11A501) From: Thomas Mangin Date: Sun, 13 Oct 2013 20:55:17 +0100 To: "rraszuk@gmail.com" X-Virus-Scanned: clamav-milter 0.97.8 at out-2-2.mail.exa.net.uk X-Virus-Status: Clean Cc: idr wg Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2013 19:55:25 -0000 Thank you Robert, I was just trying to say that what we need is demonstrate is user demand :) The QED ? was for that as it is what Randy was saying so concisely .. Perhap= s not most clear :) Sent from my iPad On 13 Oct 2013, at 20:44, Robert Raszuk wrote: >> QED ? >=20 > quod erat demonstrandum > SRC: http://en.wikipedia.org/wiki/Q.E.D. >=20 > ;-) >=20 > Cheers, > R. >=20 From randy@psg.com Sun Oct 13 20:05:16 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F2711E81DF for ; Sun, 13 Oct 2013 20:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUih6Ex2S9ec for ; Sun, 13 Oct 2013 20:05:16 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE7211E81DA for ; Sun, 13 Oct 2013 20:05:12 -0700 (PDT) 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 1VVYSr-0006pE-34; Mon, 14 Oct 2013 03:05:01 +0000 Date: Mon, 14 Oct 2013 06:05:00 +0300 Message-ID: From: Randy Bush To: Thomas Mangin In-Reply-To: <5612945F-624F-4725-AA95-8D98CA871663@exa-networks.co.uk> References: <4931A85EED76CA48BD52F2D94E7FAB0E0BB814B6@xmb-aln-x09.cisco.com> <20131013072338.GB74525@shrubbery.net> <40A136B6-737C-423E-B75F-E735D0430BE3@exa-networks.co.uk> <32787A7F-896C-4858-ABF1-185E1D2CBECA@exa-networks.co.uk> <9D3B9A0C-3BE6-4299-B22D-C759ABCEBD11@ericsson.com> <5612945F-624F-4725-AA95-8D98CA871663@exa-networks.co.uk> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IDR WG Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 03:05:17 -0000 thomas, > I was just trying to say that what we need is demonstrate is user > demand :) > The QED ? was for that as it is what Randy was saying so concisely > .. Perhaps not most clear :) two factors. first, unneeded code complexity leads to bugs, code bloat, spec bloat, ... second, complexity often increases attack surface. third (yes, you get an extra for free!) , it could get in the way of a future really needed feature. btw, we're (actually david hauweele) starting to use exabgp for injection in some experiments. thanks for the code. randy From bruno.decraene@orange.com Mon Oct 14 03:06:26 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE5521E8167 for ; Mon, 14 Oct 2013 03:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcYs0r-CIWMm for ; Mon, 14 Oct 2013 03:06:21 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id C371E21F8417 for ; Mon, 14 Oct 2013 03:00:10 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 8F9F1324554; Mon, 14 Oct 2013 11:59:22 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 7458527C053; Mon, 14 Oct 2013 11:59:22 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Mon, 14 Oct 2013 11:59:22 +0200 From: To: "Keyur Patel (keyupate)" , Robert Raszuk Thread-Topic: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHOxbaKcsvnJwdZokqbyn8GN4d0RJnubsaAgAFj74CABA/18A== Date: Mon, 14 Oct 2013 09:59:21 +0000 Message-ID: <9585_1381744762_525BC07A_9585_1496_1_53C29892C857584299CBF5D05346208A0706C5FC@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <4931A85EED76CA48BD52F2D94E7FAB0E0BB80405@xmb-aln-x09.cisco.com> In-Reply-To: <4931A85EED76CA48BD52F2D94E7FAB0E0BB80405@xmb-aln-x09.cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.27.82422 Cc: idr wg Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 10:06:27 -0000 Hi Keyur, Many thanks for the feedback. Comments are inlined #Bruno >From: Keyur Patel >Sent: Friday, October 11, 2013 10:24 PM > >Bruno, > >Apologies for the delayed response. Comments are inlined #Keyur. >> >> >> >> >>On Thu, Oct 10, 2013 at 2:45 PM, wrote: >>> Hi all, >>> >>> The draft may have two different goals: >>> -a- systematic but light checks for refreshing purpose >>> -b- "on demand" but extensive checks for troubleshooting/debugging >>>purpose > >#Keyur: Sure. > >>> >>> Because If we want to do a full check ("b"), i.e. determine which BGP >>>routing information has not been reflected, we may need to define a real >>>"snapshot" and only sends the update related to this snapshot between >>>the 2 new demarcation messages. >>> The drawback is that during this time, the BGP convergence is slow down >>>because "real time" BGP updates needs to wait for the end of this >>>snapshot. > >#Keyur: I am not sure if I agree with the above comment. Why can't an >implementation interleave routes (refresh with "real time updates")? #Bruno: If the sender interleaves routes, I don't see how the receiver coul= d detect BGP routing inconsistencies (as stated in the abstract and introdu= ction of the draft). Let's take the case of a BGP withdraw: - if they are delayed, the L3 VPN convergence is delayed. - if they are not delayed, but interleaved with the during the Route Refres= h, the receiver will detect an difference (between the RR START state and t= he RR END state) and will log an error "for further analysis". Hence we hav= e lots of error logged which are falls positive (hopefully all of them). Ho= nestly, given the ratio of falls information (>99%), I'm not sure that peop= le will do analysis of even track such logs. Even during a specific trouble= shooting, it's a bit misleading to have logs that you can't really rely on. Let's take the case of BGP update: - since they are not delayed, the receiver is equally not really capable of= detecting inconsistencies. Most/all detected inconsistencies, will be regu= lar BGP updates. So, if we don't delay BGP messages, what the draft really does is purging r= outes which should have been previously withdrawn. It does not detect incon= sistencies as the receiver can't make the distinction between an inconsiste= ncy (e.g. due to a missed BGP messages) and a normal BGP message sent durin= g the route refresh. Note that this goal would be fine for me because although the gain is more = limited, it is still interesting and the cost is null. In such case, IMO th= e draft should: - specifically states that BGP messages SHOULD NOT be delayed - update the introduction/requirements/abstract to reflect the reduced goal - add a text to explain that the logged messages do not necessarily represe= nt an error or BGP inconsistency. Quite the contrary, the vast majority of = logs are due to normal BGP operation. Thank you, Bruno >>> And this can be long (minutes, ten of minutes). Hence IMO, this is not >>>advisable for all (existing) Route Refresh. I would rather limit such >>>behavior to specific "on demand" request (e.g. through a new RR request >>>sub-type) > >#Keyur: Ack. > >Regards, >Keyur >>> >>> OTOH, if we just want to "refresh" the routes ("a"), i.e. know when to >>>purge the non-received one, we can interleave live BGP updates during >>>the refresh. This does not delay BGP convergence but we won't be able to >>>detect if there were inconsistencies and what they were. >>> >>> IMO, the draft would need to take a position between both options. >>>Eventually, it could be extended to cover both, if there is a desire for >>>this. >>> If only "a" is needed, I'm not sure to see the value of the "begin" >>>demarcation message, as the sender of RR could locally mark its route >>>when sending the RR, rather than when receiving the "RR Start" >>> >>> Thank you, >>> Bruno >>> >>> >>>_________________________________________________________________________ >>>________________________________________________ >>> >>> 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 >>_______________________________________________ >>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 Mon Oct 14 05:01:36 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E94F421E8162 for ; Mon, 14 Oct 2013 05:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+fM35ggUWmy for ; Mon, 14 Oct 2013 05:01:29 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id CBB5421E815F for ; Mon, 14 Oct 2013 05:01:26 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-35-525bdd15235e Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 75.7C.09414.51DDB525; Mon, 14 Oct 2013 14:01:26 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0328.009; Mon, 14 Oct 2013 08:01:26 -0400 From: Jakob Heitz To: "bruno.decraene@orange.com" Thread-Topic: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHOxbapvhhox5K8NESLrKRViqHbe5nuXgKAgAHZSwCABAhvgP//3w1S Date: Mon, 14 Oct 2013 12:01:25 +0000 Message-ID: References: <4931A85EED76CA48BD52F2D94E7FAB0E0BB80405@xmb-aln-x09.cisco.com>, <9585_1381744762_525BC07A_9585_1496_1_53C29892C857584299CBF5D05346208A0706C5FC@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <9585_1381744762_525BC07A_9585_1496_1_53C29892C857584299CBF5D05346208A0706C5FC@PEXCVZYM11.corporate.adroot.infra.ftgroup> 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+NgFrrBLMWRmVeSWpSXmKPExsUyuXRPiK7Y3eggg/tbBC1+7JjDbPHq9jMm i8at59ksmhY2MTuweEz5vZHVY8mSn0weLc9Osnns3riAKYAlissmJTUnsyy1SN8ugStjzeHb bAVfBSqWrnrK1sB4gbeLkZNDQsBEYvXxmewQtpjEhXvr2boYuTiEBI4ySkzau50VwlnOKDG9 YRkrSBWbgI7Et+tdzCC2iIC1xIOJIB2cHMwCuRJzL0xhBLGFBWwkdn2Zww5RYytxbWkzE4Tt JvH1wm8WEJtFQFViVdMTsBpeAXuJr01vGCGW9TJJdK2bwATicAq0MUqsPr0ErIoR6L7vp9Yw QWwTl7j1ZD4TxN0CEkv2nGeGsEUlXj7+xwpRoyOxYPcnqOu0JZYtfM0MsU1Q4uTMJywTGEVn IRk1C0nLLCQts5C0LGBkWcXIUVqcWpabbmSwiREYO8ck2HR3MO55aXmIUZqDRUmc98tb5yAh gfTEktTs1NSC1KL4otKc1OJDjEwcnFINjFqpAturk6wCn76yzv/y5Fy9wTX/uK87K/KndXxW mqCnksHNMlPw+qPdv04nf3YNenHc+IXdwrdiljlxc0ME765Pcdww7Ya+wRrbZ483VPE4/dC/ 8+vsw68r34XP9M74rXXaf8uD4g+2577bfLO6GPLcbKH8VFGzpEvXf1XKf7wXFH1lUXbEUyEl luKMREMt5qLiRAAginzjawIAAA== Cc: "Keyur Patel \(keyupate\)" , idr wg , Robert Raszuk Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 12:01:36 -0000 On Oct 14, 2013, at 3:07 AM, "bruno.decraene@orange.com" wrote: > #Bruno: If the sender interleaves routes, I don't see how the receiver co= uld detect BGP routing inconsistencies (as stated in the abstract and intro= duction of the draft). >=20 > Let's take the case of a BGP withdraw: > - if they are delayed, the L3 VPN convergence is delayed. > - if they are not delayed, but interleaved with the during the Route Refr= esh, the receiver will detect an difference (between the RR START state and= the RR END state) and will log an error "for further analysis". Hence we h= ave lots of error logged which are falls positive (hopefully all of them). = Honestly, given the ratio of falls information (>99%), I'm not sure that pe= ople will do analysis of even track such logs. Even during a specific troub= leshooting, it's a bit misleading to have logs that you can't really rely o= n. >=20 > Let's take the case of BGP update: > - since they are not delayed, the receiver is equally not really capable = of detecting inconsistencies. Most/all detected inconsistencies, will be re= gular BGP updates. >=20 > So, if we don't delay BGP messages, what the draft really does is purging= routes which should have been previously withdrawn. It does not detect inc= onsistencies as the receiver can't make the distinction between an inconsis= tency (e.g. due to a missed BGP messages) and a normal BGP message sent dur= ing the route refresh. > Note that this goal would be fine for me because although the gain is mor= e limited, it is still interesting and the cost is null. In such case, IMO = the draft should: > - specifically states that BGP messages SHOULD NOT be delayed > - update the introduction/requirements/abstract to reflect the reduced go= al > - add a text to explain that the logged messages do not necessarily repre= sent an error or BGP inconsistency. Quite the contrary, the vast majority o= f logs are due to normal BGP operation. I agree with this, except I would not even log those "normal" inconsistenci= es, just the ones after the end marker. Kind Regards, Jakob.= From keyupate@cisco.com Mon Oct 14 08:33:12 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA81A11E819F for ; Mon, 14 Oct 2013 08:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvrzEa2TmmHk for ; Mon, 14 Oct 2013 08:33:08 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id D614411E81A2 for ; Mon, 14 Oct 2013 08:33:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7344; q=dns/txt; s=iport; t=1381764788; x=1382974388; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=uG9zWv8tajR2xcHv8CpAkG3spQxiZNgHWYsY2uJTlck=; b=Njy9ckxCm/jrISTiJOzDe0sTzuXG69Ii/BK0pqqKxOuJa/4Ote7QNDKG 92/a1XdSdzwK6z4bxKsJiTp16gDjwAlX1byxTYIEjP3t1j6KdE6qHMYAC Ktluj2yPeOHq1HQZU7OMyogJpsA5VRXByHNjT5w/BExaoBpWiozrlrsIt k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFANANXFKtJXG8/2dsb2JhbABZgwc4UsF0gSUWdIIlAQEBAwEBAQE3MgIIAwUNAQgVAQIKFDcLJQIEAQ0FCId4Bgy+CwSOCAEKAYENMQeDH4EEA6oHgySBZwEIFyI X-IronPort-AV: E=Sophos;i="4.93,493,1378857600"; d="scan'208";a="271859741" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 14 Oct 2013 15:33:07 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9EFX6Jd001053 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Oct 2013 15:33:07 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.202]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Mon, 14 Oct 2013 10:33:06 -0500 From: "Keyur Patel (keyupate)" To: "bruno.decraene@orange.com" , Robert Raszuk Thread-Topic: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHOxbaKqDTLsKyCeka1DYxEyTqFhZnubsaAgAFj74CABH3LgP//5+iA Date: Mon, 14 Oct 2013 15:33:05 +0000 Message-ID: <4931A85EED76CA48BD52F2D94E7FAB0E0BB8C0CB@xmb-aln-x09.cisco.com> In-Reply-To: <9585_1381744762_525BC07A_9585_1496_1_53C29892C857584299CBF5D05346208A0706C5FC@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.61.106.83] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: idr wg Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 15:33:12 -0000 Hi Bruno, Comments inlined ##Keyur. :) On 10/14/13 2:59 AM, "bruno.decraene@orange.com" wrote: >Hi Keyur, > >Many thanks for the feedback. Comments are inlined #Bruno > >>From: Keyur Patel >Sent: Friday, October 11, 2013 10:24 PM >> >>Bruno, >> >>Apologies for the delayed response. Comments are inlined #Keyur. >>> >>> >>> >>> >>>On Thu, Oct 10, 2013 at 2:45 PM, wrote: >>>> Hi all, >>>> >>>> The draft may have two different goals: >>>> -a- systematic but light checks for refreshing purpose >>>> -b- "on demand" but extensive checks for troubleshooting/debugging >>>>purpose >> >>#Keyur: Sure. >> >>>> >>>> Because If we want to do a full check ("b"), i.e. determine which BGP >>>>routing information has not been reflected, we may need to define a >>>>real >>>>"snapshot" and only sends the update related to this snapshot between >>>>the 2 new demarcation messages. >>>> The drawback is that during this time, the BGP convergence is slow >>>>down >>>>because "real time" BGP updates needs to wait for the end of this >>>>snapshot. >> >>#Keyur: I am not sure if I agree with the above comment. Why can't an >>implementation interleave routes (refresh with "real time updates")? > >#Bruno: If the sender interleaves routes, I don't see how the receiver >could detect BGP routing inconsistencies (as stated in the abstract and >introduction of the draft). > >Let's take the case of a BGP withdraw: >- if they are delayed, the L3 VPN convergence is delayed. >- if they are not delayed, but interleaved with the during the Route >Refresh, the receiver will detect an difference (between the RR START >state and the RR END state) and will log an error "for further analysis". >Hence we have lots of error logged which are falls positive (hopefully >all of them). Honestly, given the ratio of falls information (>99%), I'm >not sure that people will do analysis of even track such logs. Even >during a specific troubleshooting, it's a bit misleading to have logs >that you can't really rely on. > >Let's take the case of BGP update: >- since they are not delayed, the receiver is equally not really capable >of detecting inconsistencies. Most/all detected inconsistencies, will be >regular BGP updates. > >So, if we don't delay BGP messages, what the draft really does is purging >routes which should have been previously withdrawn. ##Keyur: Yes. Like I said in my earlier emails, the draft tries to ensure that BGP tables exchanged between BGP Peers are consistent. Furthermore, the mechanism described in the draft assists in identifying and fixing missing withdraws. > It does not detect inconsistencies as the receiver can't make the >distinction between an inconsistency (e.g. due to a missed BGP messages) >and a normal BGP message sent during the route refresh. ##Keyur: The inconsistencies in context of both, the withdraws and the final route state announcements are detected. The draft does NOT try to address missing prefix (reachability) announcements as they cannot be solved by Route Refresh mechanisms. Furthermore, most implementations can't do snapshot for the reasons that Jakob and Randy explained in their emails. >Note that this goal would be fine for me because although the gain is >more limited, it is still interesting and the cost is null. In such case, >IMO the draft should: >- specifically states that BGP messages SHOULD NOT be delayed >- update the introduction/requirements/abstract to reflect the reduced >goal >- add a text to explain that the logged messages do not necessarily >represent an error or BGP inconsistency. Quite the contrary, the vast >majority of logs are due to normal BGP operation. ##Keyur: Super. Will do. :) Best Regards, Keyur > >Thank you, >Bruno > >>>> And this can be long (minutes, ten of minutes). Hence IMO, this is not >>>>advisable for all (existing) Route Refresh. I would rather limit such >>>>behavior to specific "on demand" request (e.g. through a new RR request >>>>sub-type) >> >>#Keyur: Ack. >> >>Regards, >>Keyur >>>> >>>> OTOH, if we just want to "refresh" the routes ("a"), i.e. know when to >>>>purge the non-received one, we can interleave live BGP updates during >>>>the refresh. This does not delay BGP convergence but we won't be able >>>>to >>>>detect if there were inconsistencies and what they were. >>>> >>>> IMO, the draft would need to take a position between both options. >>>>Eventually, it could be extended to cover both, if there is a desire >>>>for >>>>this. >>>> If only "a" is needed, I'm not sure to see the value of the "begin" >>>>demarcation message, as the sender of RR could locally mark its route >>>>when sending the RR, rather than when receiving the "RR Start" >>>> >>>> Thank you, >>>> Bruno >>>> >>>> >>>>_______________________________________________________________________ >>>>__ >>>>________________________________________________ >>>> >>>> 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 >>>_______________________________________________ >>>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. > From jhaas@slice.pfrc.org Mon Oct 14 11:50:35 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3A011E8184 for ; Mon, 14 Oct 2013 11:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.965 X-Spam-Level: X-Spam-Status: No, score=-101.965 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51UIfOYoiHHx for ; Mon, 14 Oct 2013 11:50:31 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id C6E4F11E8189 for ; Mon, 14 Oct 2013 11:50:30 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 34197C259; Mon, 14 Oct 2013 14:50:30 -0400 (EDT) Date: Mon, 14 Oct 2013 14:50:30 -0400 From: Jeffrey Haas To: John Scudder Message-ID: <20131014185030.GH17538@pfrc> References: 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) Cc: "idr@ietf. org" Subject: Re: [Idr] WG adoption requested for draft-ga-idr-as-migration X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 18:50:35 -0000 On Tue, Oct 08, 2013 at 09:17:04PM +0000, John Scudder wrote: > The authors have requested IDR adopt draft-ga-idr-as-migration as a working group document. > > http://datatracker.ietf.org/doc/draft-ga-idr-as-migration/ > > Please send any comments to the list by October 23. I support the adoption of this draft in IDR. While the draft has a lot of operational properties that are typically better suited for GROW, the fact that protocol behavior changes are documented probably make it a better fit here. -- Jeff From heas@shrubbery.net Mon Oct 14 12:04:31 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66CAE21F9951; Mon, 14 Oct 2013 12:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 093A87mcXk61; Mon, 14 Oct 2013 12:04:26 -0700 (PDT) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B99521E81A5; Mon, 14 Oct 2013 12:04:01 -0700 (PDT) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id CB3755F01; Mon, 14 Oct 2013 19:04:01 +0000 (UTC) Date: Mon, 14 Oct 2013 19:04:01 +0000 From: "heas@shrubbery.net" To: Thomas Mangin Message-ID: <20131014190401.GL14114@shrubbery.net> References: <4931A85EED76CA48BD52F2D94E7FAB0E0BB814B6@xmb-aln-x09.cisco.com> <20131013072338.GB74525@shrubbery.net> <40A136B6-737C-423E-B75F-E735D0430BE3@exa-networks.co.uk> <32787A7F-896C-4858-ABF1-185E1D2CBECA@exa-networks.co.uk> <9D3B9A0C-3BE6-4299-B22D-C759ABCEBD11@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "heas@shrubbery.net" , "idr-bounces@ietf.org" , idr wg Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 19:04:31 -0000 Sun, Oct 13, 2013 at 08:31:38PM +0100, Thomas Mangin: > Jakob, > > I will have to admit that it is more than I had in mind :) > > As I have no use for the feature myself - I just implemented it and my users are more likely to request a RR than have ExaBGP respond to one - I would rather hear from potential users about the problem they are trying to solve before trying to solve an non-issue. > > My comment was more to highlight the current limitation(s) of the draft, with a throw away idea of attribute, so it could be established if the trade off were acceptable or warrant more work on the document. > > For the moment, it is clear that more can be done to improve the feature but it is not clear at all that if it should be .. and find the value to complexity & expense? Jakob hints to the indeterminate expense from queueing updates. can't BMP be used to create a snapshot? I suppose an implementation could offer a configuration knob to queue updates. > > On 13 Oct 2013, at 18:51, Jakob Heitz wrote: > > > > I think I see what you want: > > Create a snapshot of an adj-rib-out at the "Demarcation of the beginning of a route refresh" at the sending router and have the receiving router create a similar snapshot of the corresponding adj-rib-in when it receives that demarcation. > > > > This can be potentially expensive if lots of change is happening. It is worse on the receiving router, because it has no control of when it must create the snapshot. Worse, it may need to do it for several incoming snapshots from different neighbors. To deal with this, we must invent messages and procedures to abort the snapshot. I think this is a lot harder than enhanced-route-refresh and deserves a separate draft and capability if we want to do it. > > > > I would suggest a two step procedure: first, send a hash of the snapshot in a single message and then send a real snapshot if the hash doesn't match at the receiving router. That way, you could send cheap hashes frequently and only send the expensive snapshot if an error was detected. > > > > Is there wider interest in this? presumably for research/debugging. From jakob.heitz@ericsson.com Mon Oct 14 12:17:18 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79F1021E80B7; Mon, 14 Oct 2013 12:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bJJdP2IakbA; Mon, 14 Oct 2013 12:17:11 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2B57221E80FF; Mon, 14 Oct 2013 12:17:09 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-38-525c43342a89 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 16.73.09414.4334C525; Mon, 14 Oct 2013 21:17:09 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0328.009; Mon, 14 Oct 2013 15:17:08 -0400 From: Jakob Heitz To: "heas@shrubbery.net" , Thomas Mangin Thread-Topic: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHOxbapvhhox5K8NESLrKRViqHbe5nuXgKAgAENuYCAAQF0gIAAyGWAgAFMUQCAAFALgP//81UngABerwD//8peAIAAXvoAgAGKnYD//76ukA== Date: Mon, 14 Oct 2013 19:17:07 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E02E892B8@eusaamb109.ericsson.se> References: <4931A85EED76CA48BD52F2D94E7FAB0E0BB814B6@xmb-aln-x09.cisco.com> <20131013072338.GB74525@shrubbery.net> <40A136B6-737C-423E-B75F-E735D0430BE3@exa-networks.co.uk> <32787A7F-896C-4858-ABF1-185E1D2CBECA@exa-networks.co.uk> <9D3B9A0C-3BE6-4299-B22D-C759ABCEBD11@ericsson.com> <20131014190401.GL14114@shrubbery.net> In-Reply-To: <20131014190401.GL14114@shrubbery.net> 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+NgFrrDLMWRmVeSWpSXmKPExsUyuXRPiK6pc0yQwczDghar76xlsZizcTqr xavbz5gsJm1bzerA4tF/djOTx5IlP5k8nrTeYg5gjuKySUnNySxLLdK3S+DKOL3iIlPBT/GK 1qeVDYwvhLoYOTkkBEwkjl9qYISwxSQu3FvP1sXIxSEkcJRR4uKlVUwQznJGiTPzjrKCVLEJ 6Eh8u97FDGKLCCRKnNrVxAJiMwt4SOxc8gYsLixgI3Fq9xRWiBpbiWtLm5kg7DqJV/0rweIs AqoSE39fYe9i5ODgFfCV2LxdB2LXL2aJectng13EKWAssX7+aTCbEei676fWMEHsEpe49WQ+ E8TVAhJL9pxnhrBFJV4+/scKYStLfJ/zCOo2HYkFuz+xQdjaEssWvgar5xUQlDg58wnLBEax WUjGzkLSMgtJyywkLQsYWVYxcpQWp5blphsZbGIExtAxCTbdHYx7XloeYpTmYFES5/3y1jlI SCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2PmDa3w4k2tgvvuyxQoSmyKs7m698yvRUFf+dif hruWT/DX/2zRrton6aKfp8N21Ts2/1DphEPW3zPsluyclib0h2tRRPPeft8z28J/sAavFV3e dFtd4cDtyxGZHHMvLvmXuCtnxjnne3OlJyxL15Z78XidZfI5M4uXcb+q912M4pyvzFSx9KkS S3FGoqEWc1FxIgBfD+vKbwIAAA== Cc: idr wg , "idr-bounces@ietf.org" Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 19:17:18 -0000 The enhanced route refresh as it stands will fix all routes that were eithe= r dropped or not withdrawn. This is good value already. The additional value that a snapshot gives is to tell you exactly which rou= tes were not withdrawn. Because the snapshot adds extra memory and processing requirements, if we w= ere to do this, I would like to see it with a separate capability and a sep= arate draft. Thanks, Jakob. > -----Original Message----- > From: heas@shrubbery.net [mailto:heas@shrubbery.net] > Sent: Monday, October 14, 2013 12:04 PM > To: Thomas Mangin > Cc: Jakob Heitz; heas@shrubbery.net; idr wg; idr-bounces@ietf.org > Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh >=20 > Sun, Oct 13, 2013 at 08:31:38PM +0100, Thomas Mangin: > > Jakob, > > > > I will have to admit that it is more than I had in mind :) > > > > As I have no use for the feature myself - I just implemented it and my = users > are more likely to request a RR than have ExaBGP respond to one - I would > rather hear from potential users about the problem they are trying to sol= ve > before trying to solve an non-issue. > > > > My comment was more to highlight the current limitation(s) of the draft= , > with a throw away idea of attribute, so it could be established if the tr= ade off > were acceptable or warrant more work on the document. > > > > For the moment, it is clear that more can be done to improve the featur= e > but it is not clear at all that if it should be .. >=20 > and find the value to complexity & expense? Jakob hints to the > indeterminate expense from queueing updates. can't BMP be used to > create a snapshot? >=20 > I suppose an implementation could offer a configuration knob to queue > updates. >=20 > > > On 13 Oct 2013, at 18:51, Jakob Heitz wrot= e: > > > > > > I think I see what you want: > > > Create a snapshot of an adj-rib-out at the "Demarcation of the beginn= ing > of a route refresh" at the sending router and have the receiving router > create a similar snapshot of the corresponding adj-rib-in when it receive= s > that demarcation. > > > > > > This can be potentially expensive if lots of change is happening. It = is > worse on the receiving router, because it has no control of when it must > create the snapshot. Worse, it may need to do it for several incoming > snapshots from different neighbors. To deal with this, we must invent > messages and procedures to abort the snapshot. I think this is a lot hard= er > than enhanced-route-refresh and deserves a separate draft and capability = if > we want to do it. > > > > > > I would suggest a two step procedure: first, send a hash of the snaps= hot > in a single message and then send a real snapshot if the hash doesn't mat= ch > at the receiving router. That way, you could send cheap hashes frequently > and only send the expensive snapshot if an error was detected. > > > > > > Is there wider interest in this? >=20 > presumably for research/debugging. From jhaas@slice.pfrc.org Mon Oct 14 14:37:32 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE26021E80F7 for ; Mon, 14 Oct 2013 14:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.115 X-Spam-Level: X-Spam-Status: No, score=-102.115 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXsyfVcxQc6w for ; Mon, 14 Oct 2013 14:37:26 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF4C21F9C89 for ; Mon, 14 Oct 2013 14:37:26 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 009E2C33B; Mon, 14 Oct 2013 17:37:25 -0400 (EDT) Date: Mon, 14 Oct 2013 17:37:25 -0400 From: Jeffrey Haas To: idr@ietf.org Message-ID: <20131014213725.GJ17538@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [Idr] Thought on path attribute flag reset in draft-ietf-idr-error-handling X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 21:37:33 -0000 I was reviewing some implementation details about draft-ietf-idr-error-handling earlier today. One of the items in the draft is the following: : If the "Optional bit" or the "Transitive bit" in the Attribute : Flags for an attribute conflicts with the Attribute Type Code, : then the error SHOULD be logged, and the conflicting bit in the : Attribute Flags MUST be reset to the correct value. The UPDATE : message MUST continue to be processed. This generally seems to be the right thing to do. But then I thought about the case where an implementation may choose to intentionally limit the propagation scope of a path attribute by instead setting what should be a transitive path attribute to non-transitive. In internal discussions, one comment was "well, if you really mean to do that, perhaps what you need is another path attribute". This is perhaps overkill. The point of concern for this behavior is that most of our bad behaviors over the years have been due to optional transitive issues. I'm not aware of implementations that intentionally downgrade path attributes to non-transitive. I work on an implementation that allows for path attribute filtering. (The wisdom of using such a dangerous feature is another discussion.) I'd like to hear the opinion of the working group on altering the text in draft-error-handling to instead of "MUST be reset to the correct value" to cover a behavior that permits not upgrading the transitiveness of the PA. Perhaps something like the following text: If the "Optional bit" or the "Transitive bit" in the Attribute Flags for an attribute conflicts with the Attribute Type Code, then the error SHOULD be logged. If the conflicting "Optional bit" Attribute Flag would normally be clear (mandatory), the Attribute Flags MUST be reset to their correct values. If the conflicting "Optional bit" Attribute Flag would normally be set (optional), the "Optional bit" Attribute Flag MUST be properly reset to its correct value. If the "Transitive bit" in the Attribute Flags would normally be set, but is not, the flag MAY be reset to its correct value. This is to permit the downgrading of a transitive Path Attribute to non-transitive administratively. The UPDATE message MUST continue to be processed. -- Jeff From jhaas@slice.pfrc.org Mon Oct 14 14:49:51 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F47921F9DC9 for ; Mon, 14 Oct 2013 14:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.165 X-Spam-Level: X-Spam-Status: No, score=-102.165 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+9SG+XPTd5c for ; Mon, 14 Oct 2013 14:49:46 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 636C11F0D12 for ; Mon, 14 Oct 2013 14:49:46 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 3C40FC33B; Mon, 14 Oct 2013 17:49:34 -0400 (EDT) Date: Mon, 14 Oct 2013 17:49:34 -0400 From: Jeffrey Haas To: Bill Fenner Message-ID: <20131014214933.GK17538@pfrc> References: 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) Cc: idr@ietf.org Subject: Re: [Idr] Backwards Transition in BGP4V2-MIB X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 21:49:51 -0000 [Yes, this was a while ago. No one else was apparently brave enough to answer in my absence from the list. :-) ] On Fri, Aug 23, 2013 at 01:44:57PM -0400, Bill Fenner wrote: > The backwards transition trap includes the last received notification. > There are cases when interesting backwards transitions occur and the last > sent notification provides more info about why (e.g., "cease/max prefixes > reached", "cease/admin reset"). Is it reasonable to include the last sent > notification too? What about also including the timestamps so that the > trap receiver can tell whether a given notification happened recently or a > long time ago? It's potentially reasonable to include such information. As an example, you could include the bgp4V2PeerLastErrorCodeSent and bgp4V2PeerLastErrorSubCodeSent in the OJBECTS along with bgp4V2PeerLastErrorSentTime. It's legal in SNMP to send these even if they're not in the main OBJECTS for the MIB. I think you have a fair point here - the objects we include should be either the sent or the received objects depending on whether the notification was sent or received. Do you have a suggestion on how you'd write the NOTIFICATION-TYPE with OBJECTS that are set depending on that direction? Including the timestamps for both sent and received would make it clear which was the most recent of the two pieces of information, but it seems like noise. -- Jeff From thomas.mangin@exa-networks.co.uk Mon Oct 14 15:07:28 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7735021E8193; Mon, 14 Oct 2013 15:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8IR7c2NN+Ptl; Mon, 14 Oct 2013 15:07:14 -0700 (PDT) Received: from out-9.mail.exa.net.uk (out-7.mail.exa.net.uk [82.219.4.135]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADB521E811D; Mon, 14 Oct 2013 15:07:07 -0700 (PDT) Received: from smtp-3.mail.exa.net.uk (smtp-3.mail.exa.net.uk [82.219.5.3]) by out-9.mail.exa.net.uk (ExaSMTPD) with ESMTP id 90EFEA008C; Mon, 14 Oct 2013 23:06:59 +0100 (BST) 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 67AEE6C0047; Mon, 14 Oct 2013 23:06:59 +0100 (BST) References: <20131014213725.GJ17538@pfrc> Mime-Version: 1.0 (1.0) In-Reply-To: <20131014213725.GJ17538@pfrc> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <7625F38A-C862-4F4C-A014-0E5E782CD289@exa-networks.co.uk> Cc: "idr@ietf.org" X-Mailer: iPad Mail (11A501) From: Thomas Mangin Date: Mon, 14 Oct 2013 23:06:59 +0100 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 Subject: Re: [Idr] Thought on path attribute flag reset in draft-ietf-idr-error-handling X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 22:07:29 -0000 Sent from my iPad What you propose was what ExaBGP was doing up to a few days ago when I decid= ed to simply log and ignore such messages .. I tried to explain why with draft AIGP this behaviour would lead to an inval= id transitive attribute 26 received via EBGP on a current OS to be able to r= each its IBGP peer with AIGP enabled and possibly affect the routing of the a= utonomous system. IMHO there is no excuse for such bad encoding - being liberal in what you ac= cept does not mean that BGP should become the new HTML of networking - pleas= e not :)=20 Not tearing the connection down as the invalid packet was generated a few AS= N away is fair and increase stability. What you propose would make the netwo= rk more vulnerable IMHO. Thomas From jared@puck.nether.net Mon Oct 14 17:37:12 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 265A521E813A for ; Mon, 14 Oct 2013 17:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e+8zwtVI0TLH for ; Mon, 14 Oct 2013 17:37:11 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 00E8F21E8137 for ; Mon, 14 Oct 2013 17:36:59 -0700 (PDT) Received: from [172.20.10.4] (178-146-237-139.mobile.cosmote.net [178.146.237.139]) (authenticated bits=0) by puck.nether.net (8.14.7/8.14.5) with ESMTP id r9F0amup008939 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 14 Oct 2013 20:36:51 -0400 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E02E892B8@eusaamb109.ericsson.se> Date: Mon, 14 Oct 2013 20:36:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4931A85EED76CA48BD52F2D94E7FAB0E0BB814B6@xmb-aln-x09.cisco.com> <20131013072338.GB74525@shrubbery.net> <40A136B6-737C-423E-B75F-E735D0430BE3@exa-networks.co.uk> <32787A7F-896C-4858-ABF1-185E1D2CBECA@exa-networks.co.uk> <9D3B9A0C-3BE6-4299-B22D-C759ABCEBD11@ericsson.com> <20131014190401.GL14114@shrubbery.net> <2F3EBB88EC3A454AAB08915FBF0B8C7E02E892B8@eusaamb109.ericsson.se> To: Jakob Heitz X-Mailer: Apple Mail (2.1510) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.1 (puck.nether.net [204.42.254.5]); Mon, 14 Oct 2013 20:36:54 -0400 (EDT) Cc: John Heasley , idr wg Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 00:37:12 -0000 On Oct 14, 2013, at 3:17 PM, Jakob Heitz = wrote: > The enhanced route refresh as it stands will fix all routes that were = either dropped or not withdrawn. > This is good value already. > The additional value that a snapshot gives is to tell you exactly = which routes were not withdrawn. > Because the snapshot adds extra memory and processing requirements, if = we were to do this, I would like to see it with a separate capability = and a separate draft. This sounds like a poor excuse for an original bug leaking by. Not = every defect needs to be fixed with a spec change. This seems to be unnecessary. - Jared= From bruno.decraene@orange.com Tue Oct 15 02:33:02 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 636FB11E8175 for ; Tue, 15 Oct 2013 02:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.273 X-Spam-Level: X-Spam-Status: No, score=-1.273 tagged_above=-999 required=5 tests=[AWL=-1.325, BAYES_00=-2.599, HELO_EQ_FR=0.35, MANGLED_PAIN=2.3, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pSdNKDEtqfI for ; Tue, 15 Oct 2013 02:32:58 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id 87D7C21E80B4 for ; Tue, 15 Oct 2013 02:32:53 -0700 (PDT) Received: from opfeda41.si.francetelecom.fr (unknown [10.98.245.92]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id ED62D2ACBA3; Tue, 15 Oct 2013 11:32:51 +0200 (CEST) Received: from opfeda41.si.francetelecom.fr (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 9CA9A82306_25D0BDDB; Tue, 15 Oct 2013 09:33:17 +0000 (GMT) Received: from omfeda05.si.francetelecom.fr (omfeda05.si.francetelecom.fr [xx.xx.xx.198]) by opfeda41.si.francetelecom.fr (Sophos Email Appliance) with ESMTP id 54C037F4D3_25D0BDDF; Tue, 15 Oct 2013 09:33:17 +0000 (GMT) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 59DE9180049; Tue, 15 Oct 2013 11:32:51 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Tue, 15 Oct 2013 11:32:51 +0200 From: To: Jeffrey Haas , "idr@ietf.org" Thread-Topic: [Idr] Thought on path attribute flag reset in draft-ietf-idr-error-handling Thread-Index: AQHOySWbbhiMhgJ2VUaVlwLWOL76+Zn1dh+w Date: Tue, 15 Oct 2013 09:32:50 +0000 Message-ID: <16523_1381829571_525D0BC3_16523_854_1_53C29892C857584299CBF5D05346208A0706CD09@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <20131014213725.GJ17538@pfrc> In-Reply-To: <20131014213725.GJ17538@pfrc> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.9.27.80014 Subject: Re: [Idr] Thought on path attribute flag reset in draft-ietf-idr-error-handling X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 09:33:02 -0000 Hi Jeff, all, My 2 cents inlined. >From: Jeffrey Haas >Sent: Monday, October 14, 2013 11:37 PM > >I was reviewing some implementation details about >draft-ietf-idr-error-handling earlier today. One of the items in the draft >is the following: > > >: If the "Optional bit" or the "Transitive bit" in the Attribute >: Flags for an attribute conflicts with the Attribute Type Code, >: then the error SHOULD be logged, and the conflicting bit in the >: Attribute Flags MUST be reset to the correct value. The UPDATE >: message MUST continue to be processed. > >This generally seems to be the right thing to do. But then I thought about >the case where an implementation may choose to intentionally limit the >propagation scope of a path attribute by instead setting what should be a >transitive path attribute to non-transitive. Do you mean intentionally send an erroneous PA? (IMHO, if it's not by the spec, that's an error.) >In internal discussions, one comment was "well, if you really mean to do >that, perhaps what you need is another path attribute". +1 > This is perhaps overkill. IMHO :s/overkill/overcostly And we set our own cost bar so it looks like a process concern. >The point of concern for this behavior is that most of our bad behaviors >over the years have been due to optional transitive issues. I'm not aware >of implementations that intentionally downgrade path attributes to >non-transitive. I work on an implementation that allows for path attribute >filtering. (The wisdom of using such a dangerous feature is another >discussion.) > >I'd like to hear the opinion of the working group on altering the text in >draft-error-handling to instead of "MUST be reset to the correct value" to >cover a behavior that permits not upgrading the transitiveness of the PA. >Perhaps something like the following text: >From a design point of view, on eBGP sessions, I would rather call for trea= t as withdraw because: - determining whether it's the speaker or the receiver which is wrong, does= not seem trivial to me. And if it's the receiver, and it changes the messa= ge to fit its opinion, this opens the possibility of creating errors in mul= tiple points in the network (all receivers having the same implementation).= A point I tried to raise earlier http://www.ietf.org/mail-archive/web/idr/= current/msg12053.html - this gives an incentive to the source of errors to correct its erroneous = behavior. That being said, I'm quite sure that in the reality of operational networks= , in some cases, some will prefer to keep the route (and correct the PA) in= order to restore the connectivity. So personally, on eBGP, I would call for "treat as withdraw" by default, an= d allowing the operator to change the behavior (e.g. attribute discard, att= ribute correction). > If the "Optional bit" or the "Transitive bit" in the Attribute > Flags for an attribute conflicts with the Attribute Type Code, > then the error SHOULD be logged. > > If the conflicting "Optional bit" Attribute Flag would normally be > clear (mandatory), the Attribute Flags MUST be reset to their correct > values. > > If the conflicting "Optional bit" Attribute Flag would normally be s= et > (optional), the "Optional bit" Attribute Flag MUST be properly reset > to its correct value. If the "Transitive bit" in the Attribute Flags > would normally be set, but is not, the flag MAY be reset to its > correct value. This is to permit the downgrading of a transitive Pa= th > Attribute to non-transitive administratively. FWIW, I'm not in favor of the spec allowing violation of the spec. Bruno > > The UPDATE message MUST continue to be processed. > >-- Jeff >_______________________________________________ >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 bruno.decraene@orange.com Tue Oct 15 03:17:49 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8133721F9D31 for ; Tue, 15 Oct 2013 03:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.156 X-Spam-Level: X-Spam-Status: No, score=-2.156 tagged_above=-999 required=5 tests=[AWL=0.442, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tu1bUIIRJlUW for ; Tue, 15 Oct 2013 03:17:45 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 537B011E81B7 for ; Tue, 15 Oct 2013 03:17:37 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 8453F2AC6EC; Tue, 15 Oct 2013 12:17:35 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 69976384069; Tue, 15 Oct 2013 12:17:35 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Tue, 15 Oct 2013 12:17:35 +0200 From: To: "Keyur Patel (keyupate)" , Robert Raszuk Thread-Topic: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh Thread-Index: AQHOxbaKcsvnJwdZokqbyn8GN4d0RJnubsaAgAFj74CABH3LgP//5+iAgAFY4QA= Date: Tue, 15 Oct 2013 10:17:34 +0000 Message-ID: <26655_1381832255_525D163F_26655_1147_1_53C29892C857584299CBF5D05346208A0706CDB0@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <9585_1381744762_525BC07A_9585_1496_1_53C29892C857584299CBF5D05346208A0706C5FC@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4931A85EED76CA48BD52F2D94E7FAB0E0BB8C0CB@xmb-aln-x09.cisco.com> In-Reply-To: <4931A85EED76CA48BD52F2D94E7FAB0E0BB8C0CB@xmb-aln-x09.cisco.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2011.11.18.222714 Cc: idr wg Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 10:17:49 -0000 Hi Keyur, Comments inlined ##Bruno >From: Keyur Patel (keyupate) [mailto:keyupate@cisco.com] >Sent: Monday, Oc= tober 14, 2013 5:33 PM > >Hi Bruno, > >Comments inlined ##Keyur. :) > >On 10/14/13 2:59 AM, "bruno.decraene@orange.com" > wrote: > >>Hi Keyur, >> >>Many thanks for the feedback. Comments are inlined #Bruno >> >>>From: Keyur Patel >Sent: Friday, October 11, 2013 10:24 PM >>> >>>Bruno, >>> >>>Apologies for the delayed response. Comments are inlined #Keyur. >>>> >>>> >>>> >>>> >>>>On Thu, Oct 10, 2013 at 2:45 PM, wrote: >>>>> Hi all, >>>>> >>>>> The draft may have two different goals: >>>>> -a- systematic but light checks for refreshing purpose >>>>> -b- "on demand" but extensive checks for troubleshooting/debugging >>>>>purpose >>> >>>#Keyur: Sure. >>> >>>>> >>>>> Because If we want to do a full check ("b"), i.e. determine which BGP >>>>>routing information has not been reflected, we may need to define a >>>>>real >>>>>"snapshot" and only sends the update related to this snapshot between >>>>>the 2 new demarcation messages. >>>>> The drawback is that during this time, the BGP convergence is slow >>>>>down >>>>>because "real time" BGP updates needs to wait for the end of this >>>>>snapshot. >>> >>>#Keyur: I am not sure if I agree with the above comment. Why can't an >>>implementation interleave routes (refresh with "real time updates")? >> >>#Bruno: If the sender interleaves routes, I don't see how the receiver >>could detect BGP routing inconsistencies (as stated in the abstract and >>introduction of the draft). >> >>Let's take the case of a BGP withdraw: >>- if they are delayed, the L3 VPN convergence is delayed. >>- if they are not delayed, but interleaved with the during the Route >>Refresh, the receiver will detect an difference (between the RR START >>state and the RR END state) and will log an error "for further analysis". >>Hence we have lots of error logged which are falls positive (hopefully >>all of them). Honestly, given the ratio of falls information (>99%), I'm >>not sure that people will do analysis of even track such logs. Even >>during a specific troubleshooting, it's a bit misleading to have logs >>that you can't really rely on. >> >>Let's take the case of BGP update: >>- since they are not delayed, the receiver is equally not really capable >>of detecting inconsistencies. Most/all detected inconsistencies, will be >>regular BGP updates. >> >>So, if we don't delay BGP messages, what the draft really does is purging >>routes which should have been previously withdrawn. > >##Keyur: Yes. Like I said in my earlier emails, the draft tries to ensure >that BGP tables exchanged between BGP Peers are consistent. Furthermore, >the mechanism described in the draft assists in identifying and fixing >missing withdraws. ##Bruno: Good. In think we are in sync now. 2 more minor points: - improving the consistency is good. But this assumes that the bug which cr= eate the inconsistency does not show up during the RR. Which is debatable (= as RR as likely stressing both the speaker and the receiver) :-) Also, comp= ared to current usage of RR, the requirement on the speaker to not forget t= o refresh a route is more important. Indeed, in current usage (policy chang= e, VRF provisioning) missing a route/update has likely no consequences as m= ost of the routes are already known to the receiver. While with this draft,= any missed route with result in a erroneous withdraw. Let's hope that this= will not reveal new bugs. - I don't really agree with "the draft assists in identifying and fixing mi= ssing withdraws.". Or at least, IMHO, the level of "assistance" (or Signal = / Noise) is too low to be really useful.=20 > >> It does not detect inconsistencies as the receiver can't make the >>distinction between an inconsistency (e.g. due to a missed BGP messages) >>and a normal BGP message sent during the route refresh. > >##Keyur: The inconsistencies in context of both, the withdraws and the >final route state announcements are detected.=20 ##Bruno: :s/detected/corrected (They are not really detected. Cf above) > The draft does NOT try to >address missing prefix (reachability) announcements as they cannot be >solved by Route Refresh mechanisms. Furthermore, most implementations >can't do snapshot for the reasons that Jakob and Randy explained in their >emails. > >>Note that this goal would be fine for me because although the gain is >>more limited, it is still interesting and the cost is null. In such case, >>IMO the draft should: >>- specifically states that BGP messages SHOULD NOT be delayed >>- update the introduction/requirements/abstract to reflect the reduced >>goal >>- add a text to explain that the logged messages do not necessarily >>represent an error or BGP inconsistency. Quite the contrary, the vast >>majority of logs are due to normal BGP operation. > > >##Keyur: Super. Will do. :) ##Bruno: Great. Thank you. Best regards, Bruno > >Best Regards, >Keyur > >> >>Thank you, >>Bruno >> >>>>> And this can be long (minutes, ten of minutes). Hence IMO, this is not >>>>>advisable for all (existing) Route Refresh. I would rather limit such >>>>>behavior to specific "on demand" request (e.g. through a new RR request >>>>>sub-type) >>> >>>#Keyur: Ack. >>> >>>Regards, >>>Keyur >>>>> >>>>> OTOH, if we just want to "refresh" the routes ("a"), i.e. know when to >>>>>purge the non-received one, we can interleave live BGP updates during >>>>>the refresh. This does not delay BGP convergence but we won't be able >>>>>to >>>>>detect if there were inconsistencies and what they were. >>>>> >>>>> IMO, the draft would need to take a position between both options. >>>>>Eventually, it could be extended to cover both, if there is a desire >>>>>for >>>>>this. >>>>> If only "a" is needed, I'm not sure to see the value of the "begin" >>>>>demarcation message, as the sender of RR could locally mark its route >>>>>when sending the RR, rather than when receiving the "RR Start" >>>>> >>>>> Thank you, >>>>> Bruno >>>>> >>>>> >>>>>_______________________________________________________________________ >>>>>__ >>>>>________________________________________________ >>>>> >>>>> 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 >>>>_______________________________________________ >>>>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. >> ___________________________________________________________________________= ______________________________________________ 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 jhaas@slice.pfrc.org Tue Oct 15 09:08:44 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA7CD21E81EA; Tue, 15 Oct 2013 09:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.19 X-Spam-Level: X-Spam-Status: No, score=-102.19 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hlWl9IBPvOqQ; Tue, 15 Oct 2013 09:08:39 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 112F521E81EC; Tue, 15 Oct 2013 09:08:23 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id DE75BC395; Tue, 15 Oct 2013 12:08:14 -0400 (EDT) Date: Tue, 15 Oct 2013 12:08:14 -0400 From: Jeffrey Haas To: Thomas Mangin Message-ID: <20131015160814.GO17538@pfrc> References: <20131014213725.GJ17538@pfrc> <7625F38A-C862-4F4C-A014-0E5E782CD289@exa-networks.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7625F38A-C862-4F4C-A014-0E5E782CD289@exa-networks.co.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "idr@ietf.org" , "idr-bounces@ietf.org" Subject: Re: [Idr] Thought on path attribute flag reset in draft-ietf-idr-error-handling X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 16:08:44 -0000 On Mon, Oct 14, 2013 at 11:06:59PM +0100, Thomas Mangin wrote: > What you propose was what ExaBGP was doing up to a few days ago when I decided to simply log and ignore such messages .. > > I tried to explain why with draft AIGP this behaviour would lead to an invalid transitive attribute 26 received via EBGP on a current OS to be able to reach its IBGP peer with AIGP enabled and possibly affect the routing of the autonomous system. > > IMHO there is no excuse for such bad encoding - being liberal in what you accept does not mean that BGP should become the new HTML of networking - please not :) > > Not tearing the connection down as the invalid packet was generated a few ASN away is fair and increase stability. What you propose would make the network more vulnerable IMHO. Perhaps my wording was unclear. I'm saying "if it *should* be transitive and isn't, give the user the option to leave it non-transitive". I'm definitely not saying upgrade it to transitive if it shouldn't be, like with aigp. -- Jeff From jhaas@slice.pfrc.org Tue Oct 15 09:17:12 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B771711E819E for ; Tue, 15 Oct 2013 09:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.205 X-Spam-Level: X-Spam-Status: No, score=-102.205 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UgsddYouYRE for ; Tue, 15 Oct 2013 09:17:08 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id C4D0F21F9BB6 for ; Tue, 15 Oct 2013 09:16:59 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 7A5CCC395; Tue, 15 Oct 2013 12:16:59 -0400 (EDT) Date: Tue, 15 Oct 2013 12:16:59 -0400 From: Jeffrey Haas To: bruno.decraene@orange.com Message-ID: <20131015161659.GP17538@pfrc> References: <20131014213725.GJ17538@pfrc> <16523_1381829571_525D0BC3_16523_854_1_53C29892C857584299CBF5D05346208A0706CD09@PEXCVZYM11.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16523_1381829571_525D0BC3_16523_854_1_53C29892C857584299CBF5D05346208A0706CD09@PEXCVZYM11.corporate.adroot.infra.ftgroup> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "idr@ietf.org" Subject: Re: [Idr] Thought on path attribute flag reset in draft-ietf-idr-error-handling X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 16:17:12 -0000 Bruno, On Tue, Oct 15, 2013 at 09:32:50AM +0000, bruno.decraene@orange.com wrote: > >From: Jeffrey Haas >Sent: Monday, October 14, 2013 11:37 PM > > > >I was reviewing some implementation details about > >draft-ietf-idr-error-handling earlier today. One of the items in the draft > >is the following: > > > > > >: If the "Optional bit" or the "Transitive bit" in the Attribute > >: Flags for an attribute conflicts with the Attribute Type Code, > >: then the error SHOULD be logged, and the conflicting bit in the > >: Attribute Flags MUST be reset to the correct value. The UPDATE > >: message MUST continue to be processed. > > > >This generally seems to be the right thing to do. But then I thought about > >the case where an implementation may choose to intentionally limit the > >propagation scope of a path attribute by instead setting what should be a > >transitive path attribute to non-transitive. > > Do you mean intentionally send an erroneous PA? > (IMHO, if it's not by the spec, that's an error.) I think this depends on what level of pedanticness we should consider for the PA. If the spec says that it should be optional-transitive and it's marked optional-only, the flags are not consistent with the spec but the forwarding behavior in BGP is clear all the way back to RFC 4271. More importantly, an implementation that doesn't understand the attribute couldn't enforce resetting the transitive bit appropriately. > >In internal discussions, one comment was "well, if you really mean to do > >that, perhaps what you need is another path attribute". > > +1 > > > This is perhaps overkill. > > IMHO :s/overkill/overcostly > > And we set our own cost bar so it looks like a process concern. > > > >The point of concern for this behavior is that most of our bad behaviors > >over the years have been due to optional transitive issues. I'm not aware > >of implementations that intentionally downgrade path attributes to > >non-transitive. I work on an implementation that allows for path attribute > >filtering. (The wisdom of using such a dangerous feature is another > >discussion.) > > > >I'd like to hear the opinion of the working group on altering the text in > >draft-error-handling to instead of "MUST be reset to the correct value" to > >cover a behavior that permits not upgrading the transitiveness of the PA. > >Perhaps something like the following text: > > From a design point of view, on eBGP sessions, I would rather call for treat as withdraw because: > - determining whether it's the speaker or the receiver which is wrong, does not seem trivial to me. And if it's the receiver, and it changes the message to fit its opinion, this opens the possibility of creating errors in multiple points in the network (all receivers having the same implementation). A point I tried to raise earlier http://www.ietf.org/mail-archive/web/idr/current/msg12053.html > - this gives an incentive to the source of errors to correct its erroneous behavior. This is potentially a valid argument, but not the discussion I had hoped to have. :-) The current behavior in the draft is to repair the flags to the expected positions. *** This does mean that it is not possible to permit, by spec, a change in the transitiveness of the flag without allocating a new PA code point. *** Such behavior perhaps justifies further the idea that if we want the behavior to be altered by specficiation it will require a new code point. (IDR chairs take note of this as being an important side effect of error handling as specified.) > FWIW, I'm not in favor of the spec allowing violation of the spec. At this point I'd also appeal to you as an operator to remind you that deleting path attributes is also somewhat out of spec. It's also been an unfortunately popular knob. :-/ -- Jeff From internet-drafts@ietf.org Tue Oct 15 09:33:52 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C463411E8125; Tue, 15 Oct 2013 09:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VamaJGy8Y22Q; Tue, 15 Oct 2013 09:33:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDD121F9FC8; Tue, 15 Oct 2013 09:33:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131015163349.2136.30229.idtracker@ietfa.amsl.com> Date: Tue, 15 Oct 2013 09:33:49 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-last-as-reservation-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 16:33: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 : Reservation of Last Autonomous System (AS) Numbers Author(s) : Jeffrey Haas Jon Mitchell Filename : draft-ietf-idr-last-as-reservation-01.txt Pages : 4 Date : 2013-10-15 Abstract: This document reserves two Autonomous System numbers (ASNs) at the end of the 16 bit and 32 bit ranges, described in this document as "Last ASNs" and provides guidance to implementers and operators on their use. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-last-as-reservation There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-last-as-reservation-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-last-as-reservation-01 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 Tue Oct 15 09:34:16 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACBE21E816D; Tue, 15 Oct 2013 09:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.1 X-Spam-Level: X-Spam-Status: No, score=-3.1 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlVxPgsZbUki; Tue, 15 Oct 2013 09:34:09 -0700 (PDT) Received: from out-9.mail.exa.net.uk (out-7.mail.exa.net.uk [82.219.4.135]) by ietfa.amsl.com (Postfix) with ESMTP id 25C7E21E8160; Tue, 15 Oct 2013 09:34:03 -0700 (PDT) Received: from smtp-4.mail.exa.net.uk (smtp-4.mail.exa.net.uk [82.219.5.4]) by out-9.mail.exa.net.uk (ExaSMTPD) with ESMTP id A2557A0117; Tue, 15 Oct 2013 17:34:01 +0100 (BST) Received: from ptr-34.212.219.82.rev.exa.net.uk (ptr-34.212.219.82.rev.exa.net.uk [82.219.212.34]) (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 600384006B; Tue, 15 Oct 2013 17:34:01 +0100 (BST) Content-Type: multipart/signed; boundary="Apple-Mail=_488B0B2F-D0D0-401D-B09F-0E0FFC0E636B"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Thomas Mangin In-Reply-To: <20131015160814.GO17538@pfrc> Date: Tue, 15 Oct 2013 17:34:00 +0100 Message-Id: <38B64453-5A3C-42A9-9D0D-A2BDCC9AE5E5@exa-networks.co.uk> References: <20131014213725.GJ17538@pfrc> <7625F38A-C862-4F4C-A014-0E5E782CD289@exa-networks.co.uk> <20131015160814.GO17538@pfrc> To: jhaas@slice.pfrc.org X-Mailer: Apple Mail (2.1510) X-Virus-Scanned: clamav-milter 0.97.8 at out-2-2.mail.exa.net.uk X-Virus-Status: Clean Cc: "idr@ietf.org" , "idr-bounces@ietf.org" Subject: Re: [Idr] Thought on path attribute flag reset in draft-ietf-idr-error-handling X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 16:34:16 -0000 --Apple-Mail=_488B0B2F-D0D0-401D-B09F-0E0FFC0E636B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 15 Oct 2013, at 17:08, Jeffrey Haas wrote: > On Mon, Oct 14, 2013 at 11:06:59PM +0100, Thomas Mangin wrote: >> What you propose was what ExaBGP was doing up to a few days ago when = I decided to simply log and ignore such messages .. >>=20 >> I tried to explain why with draft AIGP this behaviour would lead to = an invalid transitive attribute 26 received via EBGP on a current OS to = be able to reach its IBGP peer with AIGP enabled and possibly affect the = routing of the autonomous system. >>=20 >> IMHO there is no excuse for such bad encoding - being liberal in what = you accept does not mean that BGP should become the new HTML of = networking - please not :)=20 >>=20 >> Not tearing the connection down as the invalid packet was generated a = few ASN away is fair and increase stability. What you propose would make = the network more vulnerable IMHO. >=20 > Perhaps my wording was unclear. I'm saying "if it *should* be = transitive > and isn't, give the user the option to leave it non-transitive". =20 Thank you for the clarification. > I'm definitely not saying upgrade it to transitive if it shouldn't be, = like > with aigp. AIGP is non-transitive. I was trying to convey the case of a = purposefully malicious transitive attribute 26 created to be "bounced" = by a non-AIGP EBGP edge router, just passing what it does not = understand. But it seems this "attack" scenario is hard to explain and now off-topic = for this thread. Thomas --Apple-Mail=_488B0B2F-D0D0-401D-B09F-0E0FFC0E636B 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 iEYEARECAAYFAlJdbngACgkQA/52wvuLgaHM/ACgg4wKgU3okfPPXrg13Aa4xNKZ 4vgAn0oTzisR4g5VVNs+B/H690ImL1wB =oIvC -----END PGP SIGNATURE----- --Apple-Mail=_488B0B2F-D0D0-401D-B09F-0E0FFC0E636B-- From jhaas@slice.pfrc.org Tue Oct 15 09:51:38 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C339321E809E for ; Tue, 15 Oct 2013 09:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.215 X-Spam-Level: X-Spam-Status: No, score=-102.215 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJLVBuX1of-f for ; Tue, 15 Oct 2013 09:51:34 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7076721E80E4 for ; Tue, 15 Oct 2013 09:51:29 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 2E936C3B1; Tue, 15 Oct 2013 12:51:29 -0400 (EDT) Date: Tue, 15 Oct 2013 12:51:29 -0400 From: Jeffrey Haas To: idr@ietf.org Message-ID: <20131015165129.GS17538@pfrc> References: <20131015163349.2136.30229.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131015163349.2136.30229.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [Idr] I-D Action: draft-ietf-idr-last-as-reservation-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 16:51:38 -0000 We suspect this latest version clears any remaining issues. Given that the draft is thin IANA administravia at best, the draft may be ready for WGLC. -- Jeff On Tue, Oct 15, 2013 at 09:33:49AM -0700, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Inter-Domain Routing Working Group of the IETF. > > Title : Reservation of Last Autonomous System (AS) Numbers > Author(s) : Jeffrey Haas > Jon Mitchell > Filename : draft-ietf-idr-last-as-reservation-01.txt > Pages : 4 > Date : 2013-10-15 > > Abstract: > This document reserves two Autonomous System numbers (ASNs) at the > end of the 16 bit and 32 bit ranges, described in this document as > "Last ASNs" and provides guidance to implementers and operators on > their use. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-last-as-reservation > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-idr-last-as-reservation-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-last-as-reservation-01 > > > 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/ > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From bruno.decraene@orange.com Tue Oct 15 10:14:19 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A87011E8136 for ; Tue, 15 Oct 2013 10:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VudRVAhoksSq for ; Tue, 15 Oct 2013 10:14:15 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id DDF0D21F9EFB for ; Tue, 15 Oct 2013 10:14:14 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 0C161C0BF7; Tue, 15 Oct 2013 19:14:14 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id E30C3C806C; Tue, 15 Oct 2013 19:14:13 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Tue, 15 Oct 2013 19:14:13 +0200 From: To: Jeffrey Haas Thread-Topic: [Idr] Thought on path attribute flag reset in draft-ietf-idr-error-handling Thread-Index: AQHOycH6oteCWUb5yEepgDM0scthn5n18npA Date: Tue, 15 Oct 2013 17:14:13 +0000 Message-ID: <23536_1381857253_525D77E5_23536_11827_1_53C29892C857584299CBF5D05346208A0706D0E1@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <20131014213725.GJ17538@pfrc> <16523_1381829571_525D0BC3_16523_854_1_53C29892C857584299CBF5D05346208A0706CD09@PEXCVZYM11.corporate.adroot.infra.ftgroup> <20131015161659.GP17538@pfrc> In-Reply-To: <20131015161659.GP17538@pfrc> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.10.15.62114 Cc: "idr@ietf.org" Subject: Re: [Idr] Thought on path attribute flag reset in draft-ietf-idr-error-handling X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 17:14:19 -0000 Jeff, >From: Jeffrey Haas [mailto:jhaas@pfrc.org] >Sent: Tuesday, October 15, 201= 3 6:17 PM > >Bruno, > >On Tue, Oct 15, 2013 at 09:32:50AM +0000, bruno.decraene@orange.com wrote: >> >From: Jeffrey Haas >Sent: Monday, October 14, 2013 11:37 PM >> > >> >I was reviewing some implementation details about >> >draft-ietf-idr-error-handling earlier today. One of the items in the >draft >> >is the following: >> > >> > >> >: If the "Optional bit" or the "Transitive bit" in the Attribute >> >: Flags for an attribute conflicts with the Attribute Type Code, >> >: then the error SHOULD be logged, and the conflicting bit in the >> >: Attribute Flags MUST be reset to the correct value. The UPDATE >> >: message MUST continue to be processed. >> > >> >This generally seems to be the right thing to do. But then I thought >about >> >the case where an implementation may choose to intentionally limit the >> >propagation scope of a path attribute by instead setting what should be= a >> >transitive path attribute to non-transitive. >> >> Do you mean intentionally send an erroneous PA? >> (IMHO, if it's not by the spec, that's an error.) > >I think this depends on what level of pedanticness we should consider for >the PA. If the spec says that it should be optional-transitive and it's >marked optional-only, the flags are not consistent with the spec but the >forwarding behavior in BGP is clear all the way back to RFC 4271. Yes it's clear in RFC 4271: - if you don't recognize it, you can't check consistency with the spec. Thi= s close any further consideration (e.g. error handling behavior) - if you recognize if it, RFC 4271 calls for sending a notification. (now E= rror-handling calls for flag correction) So the level of pedanticness seems already set by RFC 4271 > More >importantly, an implementation that doesn't understand the attribute >couldn't enforce resetting the transitive bit appropriately. > >> >In internal discussions, one comment was "well, if you really mean to do >> >that, perhaps what you need is another path attribute". >> >> +1 >> >> > This is perhaps overkill. >> >> IMHO :s/overkill/overcostly >> >> And we set our own cost bar so it looks like a process concern. >> >> >> >The point of concern for this behavior is that most of our bad behaviors >> >over the years have been due to optional transitive issues. I'm not >aware >> >of implementations that intentionally downgrade path attributes to >> >non-transitive. I work on an implementation that allows for path >attribute >> >filtering. (The wisdom of using such a dangerous feature is another >> >discussion.) >> > >> >I'd like to hear the opinion of the working group on altering the text = in >> >draft-error-handling to instead of "MUST be reset to the correct value" >to >> >cover a behavior that permits not upgrading the transitiveness of the P= A. >> >Perhaps something like the following text: >> >> From a design point of view, on eBGP sessions, I would rather call for >treat as withdraw because: >> - determining whether it's the speaker or the receiver which is wrong, >does not seem trivial to me. And if it's the receiver, and it changes the >message to fit its opinion, this opens the possibility of creating errors = in >multiple points in the network (all receivers having the same >implementation). A point I tried to raise earlier http://www.ietf.org/mail- >archive/web/idr/current/msg12053.html >> - this gives an incentive to the source of errors to correct its erroneo= us >behavior. > >This is potentially a valid argument, but not the discussion I had hoped to >have. :-) > > >The current behavior in the draft is to repair the flags to the expected >positions. > >*** This does mean that it is not possible to permit, by spec, a change in >the transitiveness of the flag without allocating a new PA code point. *** > >Such behavior perhaps justifies further the idea that if we want the >behavior to be altered by specficiation it will require a new code point. >(IDR chairs take note of this as being an important side effect of error >handling as specified.) Cf above, looks to me that RFC 4271 already mandates this. >> FWIW, I'm not in favor of the spec allowing violation of the spec. > >At this point I'd also appeal to you as an operator to remind you that >deleting path attributes is also somewhat out of spec.=20 Very fair point :-) I would however try to argue that: - this is a local knob, not a spec (yes, this is pedantic. But for a spec, = saying that "it is not by the spec, but let's however consider that this is= allowed" seems a bit strange to me, except may be for a specific list of r= ecognized attributes. But this is more or less equivalent to changing the o= riginal spec to allow both options of the flags). - the spec does (obviously) not enforce that all router support optional at= tribute. Hence the router may not be able to "validate" the attribute and c= heck that it is not erroneous. Given RFC 4271 error handling, I don't want = to have all my routers supporting attribute X to shutdown their iBGP sessio= ns, just because they recognize the attribute and didn't like the flag. - I would rather say that this is allowed to remove attributes. E.g. MED, c= ommunities, extended communities (especially Route Target from a CE). And i= n the general case, RFC 4271 states a SHOULD: "Paths with unrecognized transitive optional attributes SHOULD be accepted. If a pa= th with an unrecognized transitive optional attribute is accepted [...]" > It's also been an unfortunately popular knob. :-/ "scalded cat fears cold water" (may be a French only idiom, sorry for this) (I'm afraid that this does not seem limited to BGP nowadays.) Bruno > >-- Jeff ___________________________________________________________________________= ______________________________________________ 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 jhaas@slice.pfrc.org Tue Oct 15 10:41:03 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D1921F8D0B for ; Tue, 15 Oct 2013 10:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.222 X-Spam-Level: X-Spam-Status: No, score=-102.222 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3LulFxTsIlFl for ; Tue, 15 Oct 2013 10:40:56 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2932611E8181 for ; Tue, 15 Oct 2013 10:40:52 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id C9698C395; Tue, 15 Oct 2013 13:40:51 -0400 (EDT) Date: Tue, 15 Oct 2013 13:40:51 -0400 From: Jeffrey Haas To: bruno.decraene@orange.com Message-ID: <20131015174051.GT17538@pfrc> References: <20131014213725.GJ17538@pfrc> <16523_1381829571_525D0BC3_16523_854_1_53C29892C857584299CBF5D05346208A0706CD09@PEXCVZYM11.corporate.adroot.infra.ftgroup> <20131015161659.GP17538@pfrc> <23536_1381857253_525D77E5_23536_11827_1_53C29892C857584299CBF5D05346208A0706D0E1@PEXCVZYM11.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23536_1381857253_525D77E5_23536_11827_1_53C29892C857584299CBF5D05346208A0706D0E1@PEXCVZYM11.corporate.adroot.infra.ftgroup> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "idr@ietf.org" Subject: Re: [Idr] Thought on path attribute flag reset in draft-ietf-idr-error-handling X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 17:41:03 -0000 Bruno, On Tue, Oct 15, 2013 at 05:14:13PM +0000, bruno.decraene@orange.com wrote: > Yes it's clear in RFC 4271: > - if you don't recognize it, you can't check consistency with the spec. This close any further consideration (e.g. error handling behavior) > - if you recognize if it, RFC 4271 calls for sending a notification. (now Error-handling calls for flag correction) It's obviously been too long since I've gone to that level of minutae in the spec. You're correct, of course. I've just been exposed to too many implementations that have been increasingly less picky about this due to the long discussions on error handling we've had over the years. I thus withdraw my proposal. > "scalded cat fears cold water" (may be a French only idiom, sorry for this) It's not one that I've heard before, but it's good wisdom. Now I'll have to look up the French for it. (Just don't ask me to pronounce it!) -- Jeff From internet-drafts@ietf.org Wed Oct 16 12:03:10 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF37E11E82E2; Wed, 16 Oct 2013 12:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxkwUxVciCQn; Wed, 16 Oct 2013 12:03:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1789011E82F5; Wed, 16 Oct 2013 12:03:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131016190301.16440.61368.idtracker@ietfa.amsl.com> Date: Wed, 16 Oct 2013 12:03:01 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-add-paths-09.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 19:03:11 -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 : Advertisement of Multiple Paths in BGP Author(s) : Daniel Walton Alvaro Retana Enke Chen John Scudder Filename : draft-ietf-idr-add-paths-09.txt Pages : 8 Date : 2013-10-16 Abstract: In this document we propose a BGP extension that allows the advertisement of multiple paths for the same address prefix without the new paths implicitly replacing any previous ones. The essence of the extension is that each path is identified by a path identifier in addition to the address prefix. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-add-paths There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-add-paths-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-add-paths-09 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 jgs@juniper.net Thu Oct 17 07:11:06 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6125911E826D for ; Thu, 17 Oct 2013 07:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[AWL=1.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPKjqpiiKDjj for ; Thu, 17 Oct 2013 07:11:00 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 7C87D11E8242 for ; Thu, 17 Oct 2013 07:10:50 -0700 (PDT) Received: from mail96-tx2-R.bigfish.com (10.9.14.251) by TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id 14.1.225.22; Thu, 17 Oct 2013 14:10:49 +0000 Received: from mail96-tx2 (localhost [127.0.0.1]) by mail96-tx2-R.bigfish.com (Postfix) with ESMTP id 73C9B4000DE for ; Thu, 17 Oct 2013 14:10:49 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 2 X-BigFish: VPS2(zz1519M4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzzz2fh2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h2052h20b3m1155h) Received-SPF: pass (mail96-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jgs@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(54014002)(189002)(199002)(164054003)(33656001)(85306002)(54316002)(65816001)(81686001)(76482001)(56776001)(82746002)(66066001)(80022001)(79102001)(74366001)(77982001)(63696002)(59766001)(81816001)(74876001)(83072001)(69226001)(47736001)(49866001)(50986001)(47976001)(53806001)(46102001)(51856001)(4396001)(31966008)(80976001)(74662001)(74502001)(47446002)(83322001)(74706001)(54356001)(76796001)(76786001)(36756003)(81342001)(76176001)(81542001)(77096001)(56816003)(83716002)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB527; H:DM2PR05MB527.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail96-tx2 (localhost.localdomain [127.0.0.1]) by mail96-tx2 (MessageSwitch) id 1382019047479916_8011; Thu, 17 Oct 2013 14:10:47 +0000 (UTC) Received: from TX2EHSMHS035.bigfish.com (unknown [10.9.14.234]) by mail96-tx2.bigfish.com (Postfix) with ESMTP id 71732300035 for ; Thu, 17 Oct 2013 14:10:47 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS035.bigfish.com (10.9.99.135) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 17 Oct 2013 14:10:47 +0000 Received: from DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.371.2; Thu, 17 Oct 2013 14:10:46 +0000 Received: from DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) by DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) with Microsoft SMTP Server (TLS) id 15.0.775.9; Thu, 17 Oct 2013 14:10:45 +0000 Received: from DM2PR05MB527.namprd05.prod.outlook.com ([169.254.6.207]) by DM2PR05MB527.namprd05.prod.outlook.com ([169.254.6.99]) with mapi id 15.00.0775.005; Thu, 17 Oct 2013 14:10:45 +0000 From: John Scudder To: "idr@ietf.org List" Thread-Topic: IETF-88 agenda topics Thread-Index: AQHOy0KrGHI3aXSf4Ua8aaetUQcs6w== Date: Thu, 17 Oct 2013 14:10:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 000227DA0C Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [Idr] IETF-88 agenda topics X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 14:11:06 -0000 Folks, We're planning to meet at IETF-88 on Friday, November 8 from 9:00 to 11:00.= Please forward any IDR agenda items you might have to Sue and myself. Th= e deadline is October 27 by 10:00 U.S. Eastern Time, although earlier is be= tter and in particular, try to aim for October 23. Priority will be given = to those who get their requests in early. If you have previously presented on your topic at an IDR meeting, please ex= plain in your request what you hope to achieve with your presentation this = time. If you plan to make a presentation, please keep in mind the IDR tradition, = "no Internet Draft - no time slot". You should also plan to send your slid= es to Sue and me no later than 24 hours prior to the meeting, though again,= earlier is better. Finally, if you request an agenda slot, please do so by replying to this me= ssage and don't change the subject line. Thanks, --John & Sue From farmer@umn.edu Fri Oct 18 11:14:03 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5197A11E825D for ; Fri, 18 Oct 2013 11:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebOB2wD0TGDn for ; Fri, 18 Oct 2013 11:13:50 -0700 (PDT) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.135.97]) by ietfa.amsl.com (Postfix) with ESMTP id 686C411E82E9 for ; Fri, 18 Oct 2013 11:13:50 -0700 (PDT) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Fri, 18 Oct 2013 13:13:39 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-ie0-f181.google.com [209.85.223.181] #+LO+TR X-Umn-Classification: local Received: by mail-ie0-f181.google.com with SMTP id ar20so6965070iec.26 for ; Fri, 18 Oct 2013 11:13:38 -0700 (PDT) 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:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=WS28bigi8JIDEdMe1G2HwyKP7Wsx1xJ91ri0VL1LTFY=; b=YHxkEzsAw52Edwhd1sZwTT4Xlk5bQw2nTnnqPDp9H716mx2JOYGDr7GT0k/DvSkeBs JfgwobvD1VpkDZLothRN6drWUYeQNrK3cmZhNjRIoNACtvZrz8ML1k5wnj1bAVGivk6/ riXU21psuq4eqKmKUjNybjRzVNXdP3tjVN/Ez1jhMOdAG923580/TFTlBEzN///IKJ04 8lB3V90kyeCKj3b+PlMqYcMb/88q2VCsqm1pfPryfW4Cw2koioaewXeg0fi87z49iueP uLGQDLkFqN1nlTGmQsUketcd3EBM/tYj+/IHB+ggWxjDpKQd8DMLE2kQinVlFzAmcLWC qlzw== X-Gm-Message-State: ALoCoQkDa8XFjtjIchjZSj5iuwMIeOqJIp0ckcmrlFLYeJ1ibUo0KHArENNA+AP617Bprv/u9yaHFkIjO5LdDp/9f4dIffOmw0OeI80Bwqk1wIZKJVvOlAHJatlYWyJEzfrOu6m6i0X8 X-Received: by 10.50.82.41 with SMTP id f9mr497956igy.26.1382120018966; Fri, 18 Oct 2013 11:13:38 -0700 (PDT) X-Received: by 10.50.82.41 with SMTP id f9mr497941igy.26.1382120018718; Fri, 18 Oct 2013 11:13:38 -0700 (PDT) Received: from x-134-84-88-20.nts.umn.edu (x-134-84-88-20.nts.umn.edu. [134.84.88.20]) by mx.google.com with ESMTPSA id o15sm14219398igx.6.2013.10.18.11.13.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Oct 2013 11:13:38 -0700 (PDT) Message-ID: <52617A50.30705@umn.edu> Date: Fri, 18 Oct 2013 13:13:36 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Jeffrey Haas , idr@ietf.org References: <20131015163349.2136.30229.idtracker@ietfa.amsl.com> <20131015165129.GS17538@pfrc> In-Reply-To: <20131015165129.GS17538@pfrc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Idr] I-D Action: draft-ietf-idr-last-as-reservation-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 18:14:03 -0000 Looks good to me and I also think it is ready for WGLC. On 10/15/13 11:51 , Jeffrey Haas wrote: > We suspect this latest version clears any remaining issues. Given that > the draft is thin IANA administravia at best, the draft may be ready for > WGLC. > > -- Jeff > > On Tue, Oct 15, 2013 at 09:33:49AM -0700, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Inter-Domain Routing Working Group of the IETF. >> >> Title : Reservation of Last Autonomous System (AS) Numbers >> Author(s) : Jeffrey Haas >> Jon Mitchell >> Filename : draft-ietf-idr-last-as-reservation-01.txt >> Pages : 4 >> Date : 2013-10-15 >> >> Abstract: >> This document reserves two Autonomous System numbers (ASNs) at the >> end of the 16 bit and 32 bit ranges, described in this document as >> "Last ASNs" and provides guidance to implementers and operators on >> their use. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-idr-last-as-reservation >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-idr-last-as-reservation-01 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-last-as-reservation-01 >> >> >> 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/ >> >> _______________________________________________ >> 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 > -- ================================================ 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 zhuangshunwan@huawei.com Sun Oct 20 23:28:04 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83E4E11E8355 for ; Sun, 20 Oct 2013 23:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tc-mkZVnb+nW for ; Sun, 20 Oct 2013 23:27:59 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4B511E84AC for ; Sun, 20 Oct 2013 23:27:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZG95781; Mon, 21 Oct 2013 06:27: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.146.0; Mon, 21 Oct 2013 07:27:45 +0100 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 21 Oct 2013 07:27:51 +0100 Received: from peky1z001750051 (10.111.80.111) by smtpscn.huawei.com (10.82.67.94) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 21 Oct 2013 14:27:39 +0800 From: Zhuangshunwan To: Date: Mon, 21 Oct 2013 14:27:37 +0800 Message-ID: <000401cece26$a36f1bd0$ea4d5370$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7Nqiua0KSIm0kQTbaHoa8dSByFkAAevTJQ Content-Language: zh-cn X-Originating-IP: [10.111.80.111] X-CFilter-Loop: Reflected Cc: 'Lizhenbin' Subject: [Idr] [idr] Soliciting WG feedback and comments on draft-li-idr-cc-bgp-arch-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 06:28:04 -0000 Hi: We had submitted the a new draft: = http://tools.ietf.org/html/draft-li-idr-cc-bgp-arch-00.txt, Your = feedback and comments on the IDR mailing list are appreciated. With the emergence of Software Defined Networks (SDN), BGP plays as an important part in a central controlled environment. 1 Building a central controlled framework for Controller and its Clients, BGP can be used to communicate between Controller and its Clients, Controller and other Controllers. The information carried by BGP includes network and service topology, network and service forwarding entries etc. 2 Many new applications are emerging under the centrally-controlled framework, such as network virtualization, global traffic engineering etc. Some new applications bring extension requirements to BGP. This document defines an architecture of Central Controlled BGP and then use cases under this framework are described. For some use cases requirements of BGP extensions are discussed. Thanks, Shunwan Zhuang -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2013=E5=B9=B410=E6=9C=8820=E6=97=A5 23:37 =E6=94=B6=E4=BB=B6=E4=BA=BA: Mach Chen; Shunwan Zhuang; Zhenbin Li; Mach = Chen =E4=B8=BB=E9=A2=98: New Version Notification for = draft-li-idr-cc-bgp-arch-00.txt A new version of I-D, draft-li-idr-cc-bgp-arch-00.txt has been successfully submitted by Zhenbin Li and posted to the IETF repository. Filename: draft-li-idr-cc-bgp-arch Revision: 00 Title: An Architecture of Central Controlled Border Gateway Protocol = (BGP) Creation date: 2013-10-20 Group: Individual Submission Number of pages: 12 URL: = http://www.ietf.org/internet-drafts/draft-li-idr-cc-bgp-arch-00.txt Status: = http://datatracker.ietf.org/doc/draft-li-idr-cc-bgp-arch Htmlized: http://tools.ietf.org/html/draft-li-idr-cc-bgp-arch-00 Abstract: As the Software Defined Networks (SDN) solution develops, BGP is extended to support central control. This document introduces an architecture of using BGP for central controlling. Some use cases under this new framework are also discussed. For specific use cases, making necessary extensions in BGP are required. = =20 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. The IETF Secretariat From bill.wu@huawei.com Tue Oct 22 19:39:56 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 359F011E81EA for ; Tue, 22 Oct 2013 19:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.41 X-Spam-Level: X-Spam-Status: No, score=-6.41 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyF6ORras1BR for ; Tue, 22 Oct 2013 19:39:52 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8440F11E80D9 for ; Tue, 22 Oct 2013 19:39:51 -0700 (PDT) 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 AXB78931; Wed, 23 Oct 2013 02:39:50 +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; Wed, 23 Oct 2013 03:39:49 +0100 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 23 Oct 2013 03:39:49 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.141]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0146.000; Wed, 23 Oct 2013 10:39:41 +0800 From: Qin Wu To: idr wg Thread-Topic: I-D Action: draft-wu-idr-te-pm-bgp-03.txt Thread-Index: AQHOzg6y/xApyA9UtEuFY6rq6hN5gJoBknxw Date: Wed, 23 Oct 2013 02:39:41 +0000 Message-ID: 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [Idr] FW: I-D Action: draft-wu-idr-te-pm-bgp-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 02:39:56 -0000 Hi,IDRers: The version (-03) is uploaded. The changes we made is to add "Unidirectional utilized bandwidth" as a new = metric carried in the new BGP attribute. The metric " Unidirectional utilized bandwidth " is "link utilization" metr= ic we proposed in version (-01) and discussed in the last IETF meeting. The ISIS extension for "Unidirectio= nal Utilized Bandwidth" is now moved to draft-ietf-isis-te-metric-extensions-01 based on the discussion and agre= ement happened offline. The diff is http://www.ietf.org/rfcdiff?url2=3Ddraft-wu-idr-te-pm-bgp-03 Your feedback and comments are welcome. Regards! -Qin -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] = On Behalf Of internet-drafts@ietf.org Sent: Monday, October 21, 2013 11:35 AM To: i-d-announce@ietf.org Subject: I-D Action: draft-wu-idr-te-pm-bgp-03.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : BGP attribute for North-Bound Distribution of Traffic En= gineering (TE) performance Metrics Author(s) : Qin Wu Danhua Wang Stefano Previdi Hannes Gredler Saikat Ray Filename : draft-wu-idr-te-pm-bgp-03.txt Pages : 14 Date : 2013-10-20 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-wu-idr-te-pm-bgp There's also a htmlized version available at: http://tools.ietf.org/html/draft-wu-idr-te-pm-bgp-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-wu-idr-te-pm-bgp-03 Please note that it may take a couple of minutes from the time of submissio= n 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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From matthewj@juniper.net Wed Oct 23 08:31:08 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89EA011E81AF; Wed, 23 Oct 2013 08:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqFk+j-atcCA; Wed, 23 Oct 2013 08:31:03 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id 7677B11E8439; Wed, 23 Oct 2013 08:30:58 -0700 (PDT) Received: from mail165-co1-R.bigfish.com (10.243.78.238) by CO1EHSOBE020.bigfish.com (10.243.66.83) with Microsoft SMTP Server id 14.1.225.22; Wed, 23 Oct 2013 15:30:57 +0000 Received: from mail165-co1 (localhost [127.0.0.1]) by mail165-co1-R.bigfish.com (Postfix) with ESMTP id C8703600079; Wed, 23 Oct 2013 15:30:57 +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: -25 X-BigFish: VPS-25(zz98dI9371I936eI1102I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah8275dh1de097h186068hz2fh2a8h839h946hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2052h20b3h1155h) Received-SPF: pass (mail165-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=matthewj@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(377454003)(189002)(199002)(377424004)(24454002)(43544003)(54316002)(76482001)(56776001)(74876001)(4396001)(81542001)(53806001)(81342001)(77982001)(65816001)(74366001)(19580395003)(19580405001)(83322001)(80976001)(66066001)(80022001)(79102001)(15975445006)(15202345003)(83716003)(63696002)(50986001)(47736001)(47976001)(49866001)(33656001)(85306002)(69226001)(82746002)(51856001)(81816001)(36756003)(76786001)(76796001)(77096001)(56816003)(81686001)(59766001)(74706001)(46102001)(54356001)(74662001)(74502001)(31966008)(83072001)(47446002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB226; H:BL2PR05MB225.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail165-co1 (localhost.localdomain [127.0.0.1]) by mail165-co1 (MessageSwitch) id 1382542256195035_7769; Wed, 23 Oct 2013 15:30:56 +0000 (UTC) Received: from CO1EHSMHS025.bigfish.com (unknown [10.243.78.239]) by mail165-co1.bigfish.com (Postfix) with ESMTP id 2C9572A0054; Wed, 23 Oct 2013 15:30:56 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS025.bigfish.com (10.243.66.35) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 23 Oct 2013 15:30:55 +0000 Received: from BL2PR05MB226.namprd05.prod.outlook.com (10.242.198.151) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.371.2; Wed, 23 Oct 2013 15:30:54 +0000 Received: from BL2PR05MB225.namprd05.prod.outlook.com (10.242.198.144) by BL2PR05MB226.namprd05.prod.outlook.com (10.242.198.151) with Microsoft SMTP Server (TLS) id 15.0.785.10; Wed, 23 Oct 2013 15:30:53 +0000 Received: from BL2PR05MB225.namprd05.prod.outlook.com ([169.254.2.161]) by BL2PR05MB225.namprd05.prod.outlook.com ([169.254.2.161]) with mapi id 15.00.0785.001; Wed, 23 Oct 2013 15:30:52 +0000 From: Matthew Jones To: "internet-drafts@ietf.org" Thread-Topic: [Idr] I-D Action: draft-ietf-idr-last-as-reservation-01.txt Thread-Index: AQHO0ATb57ik+14HEUu8Kl/VrBumYg== Date: Wed, 23 Oct 2013 15:30:52 +0000 Message-ID: References: <20131015163349.2136.30229.idtracker@ietfa.amsl.com> In-Reply-To: <20131015163349.2136.30229.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 000800954F Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "" , "" Subject: Re: [Idr] I-D Action: draft-ietf-idr-last-as-reservation-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 15:31:08 -0000 I *could* take care of this. I'm assuming that it means I need to change = my diff, including comments=85 +/* + * Define the private AS number address range specified in RFC 6996 + */ +#define AS_PRIV_START 64512 /**< lower bound for 2-byte private AS= range */ +#define APE_RFC6996 65534 +#define AS_PRIV_END (APE_RFC6996+1) /**< upper bound for 2-byte private AS= range. + @note exception to RFC 6996 value. + Previously AS_PRIV_END was incorrect = (it included + 65535, which is reserved), but it is = best + not to change this to avoid breaking = some deployed + networks that may be using that value= . + So, we continue to use the plus one v= alue instead + of the RFC 6996 specified value of 65= 534. */ My reading says that we are forbidden to consider 65535 as a private-as, bu= t at the same time, we should filter it on inbound. So, perhaps only my comment ne= eds to change? (i.e. the reason we cheat on the range def is so we can influence the inbou= nd filter?) I think I didn't really know the reason for the range extension, and just g= uessed=85 matthew On Oct 15, 2013, at 12:33 PM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Inter-Domain Routing Working Group of th= e IETF. >=20 > Title : Reservation of Last Autonomous System (AS) Numbers > Author(s) : Jeffrey Haas > Jon Mitchell > Filename : draft-ietf-idr-last-as-reservation-01.txt > Pages : 4 > Date : 2013-10-15 >=20 > Abstract: > This document reserves two Autonomous System numbers (ASNs) at the > end of the 16 bit and 32 bit ranges, described in this document as > "Last ASNs" and provides guidance to implementers and operators on > their use. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-last-as-reservation >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-idr-last-as-reservation-01 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-last-as-reservation-01 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 >=20 From fenner@fenron.com Thu Oct 24 08:16:34 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B36E811E8339 for ; Thu, 24 Oct 2013 08:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ge58FZkr0kwp for ; Thu, 24 Oct 2013 08:16:29 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by ietfa.amsl.com (Postfix) with ESMTP id E939911E833E for ; Thu, 24 Oct 2013 08:16:20 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id n9so1447475qcw.15 for ; Thu, 24 Oct 2013 08:16:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KgyKbJUaBVkgU/YX4bNS7A8ThQqBlyppO5yPb/UcGL8=; b=RBIWWxN11z05xe1oLgI5JtaApv3cSP8htbxQwOgTjU4FhVmz6PnEcf8Od2h9L9w6By qp7XPPG9RoVdeFrHtYy3kMPKZ/ogxCM1RwkFzbMcMQzbGZIc8w+B6mX9P8qBYG5Rhunc 78uUV45CNfbvsq/GQC8/Do4Te1kYLP7WGcUiVJxx1kY/kW2sMoG4RpRwv0uCHdiDQyjC NkZQ03rIlLfghaSAlKRC1z4CQQdmg/aRTZFRbbWy422exYxX8zFlBIXtY7etNGY139bH BzTjoMQ70wHnXAu/0Ner1ahJEceUdacBV8mkfaFebWnzCLbWBsthz7C+kE8dQ2f7dzBX QcBw== X-Gm-Message-State: ALoCoQlx3dkVxBsZy87Dqxqj+q74G8sVVY1qGqVF0W88QL2I1x2mLfsHLzbAvcvMkFgYdslHwHl0 MIME-Version: 1.0 X-Received: by 10.224.94.8 with SMTP id x8mr3954291qam.1.1382627779935; Thu, 24 Oct 2013 08:16:19 -0700 (PDT) Received: by 10.224.115.4 with HTTP; Thu, 24 Oct 2013 08:16:19 -0700 (PDT) In-Reply-To: <20131014214933.GK17538@pfrc> References: <20131014214933.GK17538@pfrc> Date: Thu, 24 Oct 2013 08:16:19 -0700 Message-ID: From: Bill Fenner To: Jeffrey Haas Content-Type: multipart/alternative; boundary=047d7b6761f6ae216c04e97e1d4e Cc: idr@ietf.org Subject: Re: [Idr] Backwards Transition in BGP4V2-MIB X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 15:16:34 -0000 --047d7b6761f6ae216c04e97e1d4e Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 14, 2013 at 2:49 PM, Jeffrey Haas wrote: > [Yes, this was a while ago. No one else was apparently brave enough to > answer in my absence from the list. :-) ] > > On Fri, Aug 23, 2013 at 01:44:57PM -0400, Bill Fenner wrote: > > The backwards transition trap includes the last received notification. > > There are cases when interesting backwards transitions occur and the > last > > sent notification provides more info about why (e.g., "cease/max prefixes > > reached", "cease/admin reset"). Is it reasonable to include the last > sent > > notification too? What about also including the timestamps so that the > > trap receiver can tell whether a given notification happened recently or > a > > long time ago? > > It's potentially reasonable to include such information. As an example, > you > could include the bgp4V2PeerLastErrorCodeSent and > bgp4V2PeerLastErrorSubCodeSent in the OJBECTS along with > bgp4V2PeerLastErrorSentTime. It's legal in SNMP to send these even if > they're not in the main OBJECTS for the MIB. > > I think you have a fair point here - the objects we include should be > either > the sent or the received objects depending on whether the notification was > sent or received. > > Do you have a suggestion on how you'd write the NOTIFICATION-TYPE with > OBJECTS that are set depending on that direction? Including the timestamps > for both sent and received would make it clear which was the most recent of > the two pieces of information, but it seems like noise. > It took a while, but I thought of it. Create new objects, that are only accessible-for-notify, that are defined as "the notification that caused the backwards transition". Bill --047d7b6761f6ae216c04e97e1d4e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Oct 14, 2013 at 2:49 PM, Jeffrey Haas <jhaas@pfrc.or= g> wrote:
[Yes, this was a while ago. =A0No one else was apparently brave enough to answer in my absence from the list. :-) ]

On Fri, Aug 23, 2013 at 01:44:57PM -0400, Bill Fenner wrote:
> The backwards transition trap includes the last received notification.=
> =A0There are cases when interesting backwards transitions occur and th= e last
> sent notification provides more info about why (e.g., "cease/max = prefixes
> reached", "cease/admin reset"). =A0Is it reasonable to = include the last sent
> notification too? =A0What about also including the timestamps so that = the
> trap receiver can tell whether a given notification happened recently = or a
> long time ago?

It's potentially reasonable to include such information. = =A0As an example, you
could include the bgp4V2PeerLastErrorCodeSent and
bgp4V2PeerLastErrorSubCodeSent in the OJBECTS along with
bgp4V2PeerLastErrorSentTime. =A0It's legal in SNMP to send these even i= f
they're not in the main OBJECTS for the MIB.

I think you have a fair point here - the objects we include should be eithe= r
the sent or the received objects depending on whether the notification was<= br> sent or received.

Do you have a suggestion on how you'd write the NOTIFICATION-TYPE with<= br> OBJECTS that are set depending on that direction? =A0Including the timestam= ps
for both sent and received would make it clear which was the most recent of=
the two pieces of information, but it seems like noise.

It took a while, but I thought of it.

=
Create new objects, that are only accessible-for-notify, that are defi= ned as "the notification that caused the backwards transition".

=A0 Bill

--047d7b6761f6ae216c04e97e1d4e-- From jhaas@slice.pfrc.org Thu Oct 24 13:43:38 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC8711E8228 for ; Thu, 24 Oct 2013 13:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.242 X-Spam-Level: X-Spam-Status: No, score=-102.242 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbaOehAtjRih for ; Thu, 24 Oct 2013 13:43:33 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 777EC11E8226 for ; Thu, 24 Oct 2013 13:43:33 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 4FF73C309; Thu, 24 Oct 2013 16:43:33 -0400 (EDT) Date: Thu, 24 Oct 2013 16:43:33 -0400 From: Jeffrey Haas To: idr@ietf.org Message-ID: <20131024204333.GS17538@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [Idr] Advancing add-path X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 20:43:38 -0000 The add-paths feature (draft-ietf-idr-add-paths) has been in I-D limbo for a little while. At this point, multiple vendors now support the feature. One sticking point of getting the draft to RFC state has been a normative reference on a document that still isn't a working group document, draft-pmohapat-idr-fast-conn-restore. In particular: : When deployed as a provider edge router or a peering router that : interacts with external neighbors, a BGP speaker usually advertises : at most one path to the internal neighbors in a network. In the case : the speaker is configured to advertise multiple paths to the internal : neighbors, it should include the Edge_Discriminator attribute defined : in [FAST-CONV] in order to make the route selection consistent inside : the network. I'm unaware of any implementation of the edge_discriminator attribute. Certainly IANA doesn't seem to have any code points allocated for it. Service Providers seem to be happy with add-paths in its current form. Has anyone seen demand for the eBGP support covered by fast-conn-restore? -- Jeff From iesg-secretary@ietf.org Wed Oct 30 08:05:50 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A700011E826A; Wed, 30 Oct 2013 08:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.356 X-Spam-Level: X-Spam-Status: No, score=-102.356 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id roEWqzeNLxWX; Wed, 30 Oct 2013 08:05:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C2D11E825E; Wed, 30 Oct 2013 08:05:45 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.81 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20131030150545.6933.11757.idtracker@ietfa.amsl.com> Date: Wed, 30 Oct 2013 08:05:45 -0700 Cc: idr@ietf.org Subject: [Idr] Last Call: (IANA Registries for BGP Extended Communities) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ietf@ietf.org List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 15:05:50 -0000 The IESG has received a request from the Inter-Domain Routing WG (idr) to consider the following document: - 'IANA Registries for BGP Extended Communities' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-11-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document reorganizes the IANA Registries for the type values and sub-type values of BGP Extended Communities attribute and the BGP IPv6-Address-Specific Extended Communities attribute. This is done in order to remove inter-dependencies among the registries, thus making it easier for IANA to determine which codepoints are available for assignment in which registries. This document also clarifies the information that must be provided to IANA when requesting an allocation from one or more of these registries. These changes are compatible with the existing allocations, and thus do not affect protocol implementations. The changes will however impact the "IANA Considerations" sections of future protocol specifications. This document updates RFCs 4360 and 5701. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-idr-extcomm-iana/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-idr-extcomm-iana/ballot/ No IPR declarations have been submitted directly on this I-D. From wwwrun@rfc-editor.org Wed Oct 30 11:19:05 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3CED11E82B1; Wed, 30 Oct 2013 11:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.437 X-Spam-Level: X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZ3KnD2Quhr5; Wed, 30 Oct 2013 11:19:03 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id D08E311E827F; Wed, 30 Oct 2013 11:19:02 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B4DF6726001; Wed, 30 Oct 2013 11:10:00 -0700 (PDT) To: ah@tr-sys.de, dmm@1-4-5.net, keyupate@cisco.com From: RFC Errata System Message-Id: <20131030181000.B4DF6726001@rfc-editor.org> Date: Wed, 30 Oct 2013 11:10:00 -0700 (PDT) Cc: idr@ietf.org, rfc-editor@rfc-editor.org, iesg@ietf.org Subject: [Idr] [Errata Held for Document Update] RFC4274 (3771) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 18:19:05 -0000 The following errata report has been held for document update for RFC4274, "BGP-4 Protocol Analysis". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4274&eid=3771 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Alfred Hoenes Date Reported: 2006-07-08 Held by: Stewart Bryant (IESG) Original Text ------------- (1) typo (missing word) The second paragraph of Section 2.2, on page 4 of RFC 4274, says: BGP uses an incremental update strategy to conserve bandwidth and | processing power. That is, after initial exchange of complete routing information, a pair of BGP routers exchanges only the changes to that information. [...] Corrected Text -------------- It should say: BGP uses an incremental update strategy to conserve bandwidth and | processing power. That is, after the initial exchange of complete routing information, a pair of BGP routers exchanges only the changes to that information. [...] Notes ----- -------------------------------------- RFC4274 (draft-ietf-idr-bgp-analysis-07) -------------------------------------- Title : BGP-4 Protocol Analysis Publication Date : January 2006 Author(s) : D. Meyer, K. Patel Category : INFORMATIONAL Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Wed Oct 30 11:22:25 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABE8E21E8133; Wed, 30 Oct 2013 11:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.439 X-Spam-Level: X-Spam-Status: No, score=-102.439 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szFywq0R1jbQ; Wed, 30 Oct 2013 11:22:25 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2D711E82CA; Wed, 30 Oct 2013 11:22:25 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A2714726001; Wed, 30 Oct 2013 11:13:22 -0700 (PDT) To: ah@tr-sys.de, dmm@1-4-5.net, keyupate@cisco.com From: RFC Errata System Message-Id: <20131030181322.A2714726001@rfc-editor.org> Date: Wed, 30 Oct 2013 11:13:22 -0700 (PDT) Cc: idr@ietf.org, rfc-editor@rfc-editor.org, iesg@ietf.org Subject: [Idr] [Errata Held for Document Update] RFC4274 (3772) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 18:22:25 -0000 The following errata report has been held for document update for RFC4274, "BGP-4 Protocol Analysis". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4274&eid=3772 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Alfred Hoenes Date Reported: 2006-07-08 Held by: Stewart Bryant (IESG) Original Text ------------- (2) typo Section 2.3 contains (on page 5) the state description: ACTIVE: State in which BGP peer is trying to acquire a peer | by listening and accepting TCP connection. Corrected Text -------------- ACTIVE: State in which BGP peer is trying to acquire a peer | by listening and accepting a TCP connection. ^^^ (An alternative correction, replacing 'connection' by 'connections', does not precisely reflect the desired behaviour.) Notes ----- from errata 148 -------------------------------------- RFC4274 (draft-ietf-idr-bgp-analysis-07) -------------------------------------- Title : BGP-4 Protocol Analysis Publication Date : January 2006 Author(s) : D. Meyer, K. Patel Category : INFORMATIONAL Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Wed Oct 30 11:29:47 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 359D411E818B; Wed, 30 Oct 2013 11:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqRMJfEukfen; Wed, 30 Oct 2013 11:29:46 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id B6D6E11E8182; Wed, 30 Oct 2013 11:29:46 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 94E0A726001; Wed, 30 Oct 2013 11:20:44 -0700 (PDT) To: ah@tr-sys.de, dmm@1-4-5.net, keyupate@cisco.com From: RFC Errata System Message-Id: <20131030182044.94E0A726001@rfc-editor.org> Date: Wed, 30 Oct 2013 11:20:44 -0700 (PDT) Cc: idr@ietf.org, rfc-editor@rfc-editor.org, iesg@ietf.org Subject: [Idr] [Errata Held for Document Update] RFC4274 (3773) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 18:29:47 -0000 The following errata report has been held for document update for RFC4274, "BGP-4 Protocol Analysis". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4274&eid=3773 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Alfred Hoenes Date Reported: 2006-07-08 Held by: Stewart Bryant (IESG) Original Text ------------- (3) typos (multiple missing articles) Section 4 of RFC 4274, on page 6, says: Whenever a BGP speaker detects an error in a peer connection, it shuts down the peer and changes its FSM state to IDLE. BGP speaker requires a Start event to re-initiate an idle peer connection. If the error remains persistent and BGP speaker generates a Start event automatically, then it may result in persistent peer flapping. Although peer oscillation is found to be wide-spread in BGP implementations, methods for preventing persistent peer oscillations are outside the scope of base BGP specification. Corrected Text -------------- It should say: Whenever a BGP speaker detects an error in a peer connection, it | shuts down the peer and changes its FSM state to IDLE. A BGP speaker requires a Start event to re-initiate an idle peer connection. If | the error remains persistent and the BGP speaker generates a Start event automatically, then it may result in persistent peer flapping. Although peer oscillation is found to be wide-spread in BGP implementations, methods for preventing persistent peer oscillations | are outside the scope of the base BGP specification. Notes ----- from errata 148 -------------------------------------- RFC4274 (draft-ietf-idr-bgp-analysis-07) -------------------------------------- Title : BGP-4 Protocol Analysis Publication Date : January 2006 Author(s) : D. Meyer, K. Patel Category : INFORMATIONAL Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Wed Oct 30 11:36:09 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF6321E813A; Wed, 30 Oct 2013 11:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.444 X-Spam-Level: X-Spam-Status: No, score=-102.444 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VozZuhnLht9S; Wed, 30 Oct 2013 11:35:58 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id B32BC11E81A5; Wed, 30 Oct 2013 11:35:28 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A47C7726001; Wed, 30 Oct 2013 11:26:25 -0700 (PDT) To: ah@tr-sys.de, dmm@1-4-5.net, keyupate@cisco.com From: RFC Errata System Message-Id: <20131030182625.A47C7726001@rfc-editor.org> Date: Wed, 30 Oct 2013 11:26:25 -0700 (PDT) Cc: idr@ietf.org, rfc-editor@rfc-editor.org, iesg@ietf.org Subject: [Idr] [Errata Held for Document Update] RFC4274 (3774) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 18:36:09 -0000 The following errata report has been held for document update for RFC4274, "BGP-4 Protocol Analysis". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4274&eid=3774 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Alfred Hoenes Date Reported: 2006-07-08 Held by: Stewart Bryant (IESG) Original Text ------------- (6) typos / grammar In Section 10, the second paragraph on page 13 says: | BGP uses TCP MD5 option for validating data and protecting against spoofing of TCP segments exchanged between its sessions. The usage of TCP MD5 option for BGP is described at length in [RFC2385]. The TCP MD5 Key management is discussed in [RFC3562]. BGP data | encryption is provided using the IPsec mechanism, which encrypts the | IP payload data (including TCP and BGP data). The IPsec mechanism | can be used in both the transport mode and the tunnel mode. The | IPsec mechanism is described in [RFC2406]. Both the TCP MD5 option | and the IPsec mechanism are not widely deployed security mechanisms for BGP in today's Internet. Hence, it is difficult to gauge their | real performance impact when using with BGP. However, because both | the mechanisms are TCP- and IP-based security mechanisms, the Link Bandwidth, CPU utilization and router memory consumed by BGP would be | the same as any other TCP- and IP-based protocols. It should say, correcting grammar and unclear semantics: | BGP uses the TCP MD5 option for validating data and protecting against spoofing of TCP segments exchanged between its sessions. The usage of TCP MD5 option for BGP is described at length in [RFC2385]. The TCP MD5 Key management is discussed in [RFC3562]. BGP data | encryption is provided using the IPsec ESP mechanism, which encrypts | the IP payload data (including TCP and BGP data). The IPsec ESP | mechanism can be used in both transport mode and tunnel mode. The | IPsec ESP mechanism is described in [RFC2406]. Both the TCP MD5 | option and IPsec ESP are not widely deployed security mechanisms for BGP in today's Internet. Hence, it is difficult to gauge their | real performance impact when used with BGP. However, because both | mechanisms are TCP- and IP-based security mechanisms, the Link Bandwidth, CPU utilization and router memory consumed by BGP would be the same as any for other TCP- and IP-based protocols. (I am in doubt whether the last sentence is appropriate; at least, "the same as" should better be replaced by "similar as". Preferrably, I would delete that sentence.) Finally, the 4th paragraph on page 13, v | Such flexible TCP- and IP-based security mechanisms, allow BGP to prevent insertion/deletion/modification of BGP data, any snooping of the data, session stealing, etc. [...] should say: | Such flexible TCP- and IP-based security mechanisms allow BGP to prevent insertion/deletion/modification of BGP data, any snooping of the data, session stealing, etc. [...] Corrected Text -------------- Notes ----- from errata 148 -------------------------------------- RFC4274 (draft-ietf-idr-bgp-analysis-07) -------------------------------------- Title : BGP-4 Protocol Analysis Publication Date : January 2006 Author(s) : D. Meyer, K. Patel Category : INFORMATIONAL Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Wed Oct 30 11:44:29 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A9011E82C4; Wed, 30 Oct 2013 11:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.447 X-Spam-Level: X-Spam-Status: No, score=-102.447 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3UDjKSNSqlN; Wed, 30 Oct 2013 11:44:27 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF7821F9FB0; Wed, 30 Oct 2013 11:43:58 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id D238D726001; Wed, 30 Oct 2013 11:34:49 -0700 (PDT) To: ah@tr-sys.de, dmm@1-4-5.net, keyupate@cisco.com From: RFC Errata System Message-Id: <20131030183449.D238D726001@rfc-editor.org> Date: Wed, 30 Oct 2013 11:34:49 -0700 (PDT) Cc: idr@ietf.org, rfc-editor@rfc-editor.org, iesg@ietf.org Subject: [Idr] [Errata Rejected] RFC4274 (3775) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 18:44:29 -0000 The following errata report has been rejected for RFC4274, "BGP-4 Protocol Analysis". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4274&eid=3775 -------------------------------------- Status: Rejected Type: Editorial Reported by: Alfred Hoenes Date Reported: 2006-07-08 Rejected by: Stewart Bryant (IESG) Original Text ------------- (7) some Ref's inappropriately named Normative The References "[BGP-VULN]" and "[SBGP]" do not fulfill the criteria for being used as Normative References. Their inclusion in Section 11.1, on page 14, might formally be seen as inhibiting the progress of BGP-4 on the Standards Track. Corrected Text -------------- Notes ----- This was considered OK by the IETF and IESG of the time. --VERIFIER NOTES-- The status of these references will have been considered by the IETF and the IESG of the time. The authors and reviewers of any future BGP document will evaluate the correct status of the references that they use. -------------------------------------- RFC4274 (draft-ietf-idr-bgp-analysis-07) -------------------------------------- Title : BGP-4 Protocol Analysis Publication Date : January 2006 Author(s) : D. Meyer, K. Patel Category : INFORMATIONAL Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Wed Oct 30 11:49:06 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4603611E81A8; Wed, 30 Oct 2013 11:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfVuvHa2KnuO; Wed, 30 Oct 2013 11:49:05 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 085BE11E818B; Wed, 30 Oct 2013 11:49:05 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B815A726001; Wed, 30 Oct 2013 11:40:02 -0700 (PDT) To: ah@tr-sys.de, dmm@1-4-5.net, keyupate@cisco.com From: RFC Errata System Message-Id: <20131030184002.B815A726001@rfc-editor.org> Date: Wed, 30 Oct 2013 11:40:02 -0700 (PDT) Cc: idr@ietf.org, rfc-editor@rfc-editor.org, iesg@ietf.org Subject: [Idr] [Errata Held for Document Update] RFC4274 (3776) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 18:49:06 -0000 The following errata report has been held for document update for RFC4274, "BGP-4 Protocol Analysis". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4274&eid=3776 -------------------------------------- Status: Held for Document Update Type: Technical Reported by: Alfred Hoenes Date Reported: 2006-07-08 Held by: Stewart Bryant (IESG) Original Text ------------- (4) inconsistency in updated text The text of section 6.1 has been revised substantially from its predecessor, RFC 1774. Unfortunately, the modifications have not been performed incompletely, leading to near-nonsense text. Section 6.1, on page 7, says: Immediately after the initial BGP connection setup, BGP peers exchange complete sets of routing information. If we denote the total number of routes in the Internet as N, the total path attributes (for all N routes) received from a peer as A, and assume that the networks are uniformly distributed among the autonomous systems, then the worst-case amount of bandwidth consumed during the | initial exchange between a pair of BGP speakers (P) is | BW = O((N + A) * P) ^^^^ ^^^^^ This makes no sense -- obviously you can't multiply by a non-numeric quantity P, "a pair of BGP speakers". I strongly suspect that it was the intention to say: Immediately after the initial BGP connection setup, BGP peers exchange complete sets of routing information. If we denote the total number of routes in the Internet as N, the total path attributes (for all N routes) received from a peer as A, and assume that the networks are uniformly distributed among the autonomous systems, then the worst-case amount of bandwidth consumed during the | initial exchange between a pair of BGP speakers is | BW = O((N + A)) Please verify. Corrected Text -------------- Notes ----- from errata 148 This has no impact on interoperability. It should be looked at on any update of the RFC. -------------------------------------- RFC4274 (draft-ietf-idr-bgp-analysis-07) -------------------------------------- Title : BGP-4 Protocol Analysis Publication Date : January 2006 Author(s) : D. Meyer, K. Patel Category : INFORMATIONAL Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Wed Oct 30 11:53:22 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C32C21F9F0A; Wed, 30 Oct 2013 11:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.451 X-Spam-Level: X-Spam-Status: No, score=-102.451 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZY3t3IiYeg9; Wed, 30 Oct 2013 11:53:21 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 210AD21E8143; Wed, 30 Oct 2013 11:53:20 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E30D8726001; Wed, 30 Oct 2013 11:44:10 -0700 (PDT) To: ah@tr-sys.de, dmm@1-4-5.net, keyupate@cisco.com From: RFC Errata System Message-Id: <20131030184410.E30D8726001@rfc-editor.org> Date: Wed, 30 Oct 2013 11:44:10 -0700 (PDT) Cc: idr@ietf.org, rfc-editor@rfc-editor.org, iesg@ietf.org Subject: [Idr] [Errata Held for Document Update] RFC4274 (3777) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 18:53:22 -0000 The following errata report has been held for document update for RFC4274, "BGP-4 Protocol Analysis". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4274&eid=3777 -------------------------------------- Status: Held for Document Update Type: Technical Reported by: Alfred Hoenes Date Reported: 2006-07-08 Held by: Stewart Bryant (IESG) Original Text ------------- (5) like (4) Section 6.1.2, on page 8, exhibits similar symptoms as noted above. The RFC says: To quantify the worst-case memory requirements for BGP, we denote the total number of networks in the Internet as N, the mean AS distance of the Internet as M (distance at the level of an autonomous system, expressed in terms of the number of autonomous systems), the total number of unique AS paths as A. Then the worst-case memory requirements (MR) can be expressed as MR = O(N + (M * A)) Because a mean AS distance M is a slow moving function of the interconnectivity ("meshiness") of the Internet, for all practical purposes the worst-case router memory requirements are on the order | of the total number of networks in the Internet multiplied by the | number of peers that the local system is peering with. [...] Apparently, the first part of that text has been revised eliminating the role of the peering count. Thus the last sentence should have been updated accordingly, to make it match the new formula. The second paragraph thus perhaps should say: Because a mean AS distance M is a slow moving function of the interconnectivity ("meshiness") of the Internet, for all practical purposes the worst-case router memory requirements are on the order | of the total number of networks in the Internet. [...] Corrected Text -------------- Notes ----- from errata 148 Rather than follow this suggestion (and drop the number of peers term out of the prose) it may be more would be more accurate to insert a number of peers term into the formula, e.g. MR = O(P * (N + (M * A))), where P is the number of peers. This does not impact interoperability and thus should be looked at in any future update of the RFC. -------------------------------------- RFC4274 (draft-ietf-idr-bgp-analysis-07) -------------------------------------- Title : BGP-4 Protocol Analysis Publication Date : January 2006 Author(s) : D. Meyer, K. Patel Category : INFORMATIONAL Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Wed Oct 30 11:56:25 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5195311E818E; Wed, 30 Oct 2013 11:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.453 X-Spam-Level: X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIHNqdfLdclB; Wed, 30 Oct 2013 11:56:24 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id D323E21E8091; Wed, 30 Oct 2013 11:56:19 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 97B83726001; Wed, 30 Oct 2013 11:47:17 -0700 (PDT) To: ah@tr-sys.de, dmm@1-4-5.net, keyupate@cisco.com From: RFC Errata System Message-Id: <20131030184717.97B83726001@rfc-editor.org> Date: Wed, 30 Oct 2013 11:47:17 -0700 (PDT) Cc: idr@ietf.org, rfc-editor@rfc-editor.org, iesg@ietf.org Subject: [Idr] [Errata Held for Document Update] RFC4274 (148) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 18:56:25 -0000 The following errata report has been held for document update for RFC4274, "BGP-4 Protocol Analysis". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4274&eid=148 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Alfred Hoenes Date Reported: 2006-07-08 Held by: Stewart Bryant (IESG) Original Text ------------- The final paragraph on page 8, The following table illustrates typical memory requirements of a router running BGP. We denote the average number of routes advertised by each peer as N, the total number of unique AS paths as A, the mean AS distance of the Internet as M (distance at the level of an autonomous system, expressed in terms of the number of autonomous systems), the number of octets required to store a network as R, and the number of bytes required to store one AS in an AS path | as P. It is assumed that each network is encoded as four bytes, each AS is encoded as two bytes, and each networks is reachable via some | fraction of all the peers (# BGP peers/per net). For purposes of the | estimates here, we will calculate MR = (((N * R) + (M * A) * P) * S). ^^^^ ^^^^ and the table on page 9, vvvvvvvvvvvvvvvvvvv | # Networks Mean AS Distance # ASes # BGP peers/per net Memory Req | (N) (M) (A) (P) (MR) ---------- ---------------- ------ ------------------- ------------- 100,000 20 3,000 20 10,400,000 100,000 20 15,000 20 20,000,000 120,000 10 15,000 100 78,000,000 140,000 15 20,000 100 116,000,000 exhibit additional issues: - The text defines 'P' as "the number of bytes required to store one AS in an AS path" while apparently in the table (P) means "# BGP peers/per net". - 'S' in the formula in the last line of page 9 is not defined anywhere in the text. - "# BGP peers/per net" IMHO does not even make sense in the context of BGP, since BGP speakers represent ASes, not networks (prefixes). I do not have a proposal for an easy way to get rid of these inconsistencies. Please check. Corrected Text -------------- Notes ----- There is clearly a problem with the text, but it does not impact interoperability and should be looked at when the RFC is revised. -------------------------------------- RFC4274 (draft-ietf-idr-bgp-analysis-07) -------------------------------------- Title : BGP-4 Protocol Analysis Publication Date : January 2006 Author(s) : D. Meyer, K. Patel Category : INFORMATIONAL Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From jgs@juniper.net Wed Oct 30 12:26:33 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2994B11E819A for ; Wed, 30 Oct 2013 12:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.874 X-Spam-Level: X-Spam-Status: No, score=-3.874 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cM8ZRjVw9Zc for ; Wed, 30 Oct 2013 12:26:28 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id 58F7111E818E for ; Wed, 30 Oct 2013 12:26:26 -0700 (PDT) Received: from mail115-va3-R.bigfish.com (10.7.14.245) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.22; Wed, 30 Oct 2013 19:26:25 +0000 Received: from mail115-va3 (localhost [127.0.0.1]) by mail115-va3-R.bigfish.com (Postfix) with ESMTP id 5646740008D; Wed, 30 Oct 2013 19:26:25 +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: -15 X-BigFish: VPS-15(zzda00hdc73hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzz1033IL17326ah8275dh1de097h186068h17598djz2fh2a8h839h946hd25he5bhf0ah1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e23h1fe8h1ff5h2052h20b3h2218h2216h1155h) Received-SPF: pass (mail115-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jgs@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(47976001)(47736001)(49866001)(81686001)(50226001)(15202345003)(53806001)(50986001)(36756003)(33656001)(51856001)(46102001)(42186004)(74876001)(80022001)(50466002)(66066001)(558084003)(74706001)(4396001)(77096001)(83072001)(79102001)(80976001)(76786001)(82746002)(56816003)(15975445006)(65816001)(19580395003)(76796001)(87286001)(87266001)(31966008)(47446002)(23746002)(83322001)(63696002)(47776003)(74662001)(74502001)(77982001)(59766001)(85306002)(62966002)(76482001)(54316002)(69226001)(81342001)(81542001)(56776001)(77156001)(74366001)(81816001)(83716003)(57306001)(42262001)(15302535010); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB527; H:[172.28.130.250]; CLIP:66.129.241.15; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail115-va3 (localhost.localdomain [127.0.0.1]) by mail115-va3 (MessageSwitch) id 1383161184164235_16736; Wed, 30 Oct 2013 19:26:24 +0000 (UTC) Received: from VA3EHSMHS014.bigfish.com (unknown [10.7.14.244]) by mail115-va3.bigfish.com (Postfix) with ESMTP id 24039440040; Wed, 30 Oct 2013 19:26:24 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS014.bigfish.com (10.7.99.24) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 30 Oct 2013 19:26:23 +0000 Received: from DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.371.2; Wed, 30 Oct 2013 19:26:23 +0000 Received: from [172.28.130.250] (66.129.241.15) by DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) with Microsoft SMTP Server (TLS) id 15.0.815.6; Wed, 30 Oct 2013 19:26:21 +0000 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: "John G. Scudder" In-Reply-To: Date: Wed, 30 Oct 2013 15:26:14 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <8257A6FD-37A7-40AA-947C-5D52584B60FB@juniper.net> References: To: "idr@ietf. org" X-Mailer: Apple Mail (2.1816) X-Originating-IP: [66.129.241.15] X-ClientProxiedBy: BY2PR05CA010.namprd05.prod.outlook.com (10.242.32.40) To DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) X-Forefront-PRVS: 00159D1518 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [Idr] IETF-88 agenda topics X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 19:26:33 -0000 Agenda is uploaded: = http://www.ietf.org/proceedings/88/agenda/agenda-88-idr If you requested a slot and we missed it, please let us know ASAP. =97John= From wwwrun@rfc-editor.org Thu Oct 31 04:18:57 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CAFC21E80C4; Thu, 31 Oct 2013 04:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.457 X-Spam-Level: X-Spam-Status: No, score=-102.457 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frDhwH1JUaDr; Thu, 31 Oct 2013 04:18:56 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 0A89921E80CB; Thu, 31 Oct 2013 04:18:54 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 514D062187; Thu, 31 Oct 2013 04:09:49 -0700 (PDT) To: ramakrishnadtv@infosys.com, tbates@cisco.com, enkechen@cisco.com, rchandra@sonoasystems.com From: RFC Errata System Message-Id: <20131031110949.514D062187@rfc-editor.org> Date: Thu, 31 Oct 2013 04:09:49 -0700 (PDT) Cc: idr@ietf.org, rfc-editor@rfc-editor.org, iesg@ietf.org Subject: [Idr] [Errata Held for Document Update] RFC4456 (3778) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 11:18:57 -0000 The following errata report has been held for document update for RFC4456, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4456&eid=3778 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Ramakrishna DTV Date Reported: 2013-10-30 Held by: Stewart Bryant (IESG) Section: 5 Original Text ------------- The Non-Client peer must be fully meshed but the Client peers need not be fully meshed. Corrected Text -------------- The Non-Client peers must be fully meshed but the Client peers need not be fully meshed. Notes ----- This is a typo. Figure 4 shows multiple Non-Client peers. But the text is referring to "The Non-Client peer". It should be "The Non-Client peers". -------------------------------------- RFC4456 (draft-ietf-idr-rfc2796bis-02) -------------------------------------- Title : BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP) Publication Date : April 2006 Author(s) : T. Bates, E. Chen, R. Chandra Category : DRAFT STANDARD Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Wed Oct 30 22:57:13 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7BF11E81CB for ; Wed, 30 Oct 2013 22:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.455 X-Spam-Level: X-Spam-Status: No, score=-102.455 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9s6Pq6PqXz9f for ; Wed, 30 Oct 2013 22:57:12 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6D011E80FE for ; Wed, 30 Oct 2013 22:57:12 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 2542362187; Wed, 30 Oct 2013 22:48:08 -0700 (PDT) To: tbates@cisco.com, enkechen@cisco.com, rchandra@sonoasystems.com, stbryant@cisco.com, adrian@olddog.co.uk, shares@ndzh.com, jgs@juniper.net From: RFC Errata System Message-Id: <20131031054808.2542362187@rfc-editor.org> Date: Wed, 30 Oct 2013 22:48:08 -0700 (PDT) X-Mailman-Approved-At: Thu, 31 Oct 2013 06:22:53 -0700 Cc: idr@ietf.org, rfc-editor@rfc-editor.org Subject: [Idr] [Editorial Errata Reported] RFC4456 (3778) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 05:57:13 -0000 The following errata report has been submitted for RFC4456, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4456&eid=3778 -------------------------------------- Type: Editorial Reported by: Ramakrishna DTV Section: 5 Original Text ------------- The Non-Client peer must be fully meshed but the Client peers need not be fully meshed. Corrected Text -------------- The Non-Client peers must be fully meshed but the Client peers need not be fully meshed. Notes ----- This is a typo. Figure 4 shows multiple Non-Client peers. But the text is referring to "The Non-Client peer". It should be "The Non-Client peers". 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. -------------------------------------- RFC4456 (draft-ietf-idr-rfc2796bis-02) -------------------------------------- Title : BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP) Publication Date : April 2006 Author(s) : T. Bates, E. Chen, R. Chandra Category : DRAFT STANDARD Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG