Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA09167 for ; Fri, 16 Feb 2001 19:25:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 34D535DECE; Fri, 16 Feb 2001 19:24:05 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A5FE75DED2; Fri, 16 Feb 2001 19:24:04 -0500 (EST) Received: from CLYNN.BBN.COM (CLynn.BBN.COM [128.89.1.209]) by segue.merit.edu (Postfix) with SMTP id 736BA5DECE for ; Fri, 16 Feb 2001 19:23:58 -0500 (EST) Date: Fri, 16 Feb 2001 19:21:13 +0500 (EST) From: Charles Lynn To: idr@merit.edu Cc: Dmitri Krioukov , Mark Mentovai , Charles Lynn Subject: Re: handling unrecognized optional transitive attributes Message-Id: <20010217002358.736BA5DECE@segue.merit.edu> Sender: owner-idr@merit.edu Precedence: bulk Following up on a few points... Dima notes: it's easier to imagine an optional transitive attribute with semantics such that even if all routes being aggregated have the identical value of this attribute, the attribute value for the aggregated route is not supposed to be the same. Yes. Perhaps simply not aggregating routes with unknown transitive path attributes would be better. Andrew said that most folks upgrade their s/w fairly often. I suspect, but could be mistaken, that those are the same folks that need to aggregate. Thus specifying a behavior that would be better in the long run (which may or may not be what happens today) should be quickly deployed where aggregation is needed. Mark asks: Are there any (real, not imaginary) used or proposed optional transitive attributes that would break under the "copy if all identical, else drop" scheme under discussion? It depends on the definition of "break". Lets consider the meaning to be "would cause routes to be accepted and/or propagated that are inconsistent with administration policy". Here are a couple of examples based on others' comments: Enke commented: Also, it seems to me that the question of "what might happen with choice 1" has been answered for quite some time. The COMMUNITY attribute which is optional transitive was introduced and deployed (quite smoothly if I remember correctly). Is the claim that when a community attribute carrying the well-known community NO-EXPORT is dropped by an aggregating AS, that the associated routes are not exported to other ASes? It seems to me that dropping the attribute would, in fact, cause something to "break". Maybe NO-EXPORT isn't being used; maybe it isn't being used BECAUSE folks see that the aggregation actions currently deployed are "broken", in this situation; maybe ASes were not doing much aggregation when the deployment happened. Mark states: The proposed NEW_AS_PATH and NEW_AGGREGATOR also don't seem to pose a problem. (I am still digesting draft-ietf-idr-as4bytes-01, so please correct me if my understanding is wrong...) As I understand the rules, a 32-bit AS# capable AS that sends a route to a 16-bit AS# AS inserts NEW_AS_PATH to carry the 32-bit AS numbers. If the 16-bit AS# only AS then aggregates the route (given that the AS_PATH attributes of the to be aggregated routes all have 16-bit AS#s and the generic AS_TRANS AS# in just the right places) and drops the NEW_AS_PATH before forwarding it on to another 32-bit AS# AS, hasn't that "broken" AS path filtering for the receiving 32-bit AS# AS? If so, I would call that "a problem". (Of course, the next version of the draft may change the way things are done to address this issue, given the currently deployed Choice 1. Or maybe nobody cares about AS path filtering; or maybe the cost to fix the deployed code is greater than the cost of a violated policy; or maybe ...) One could also use a weaker definition of "break" that has semantics of "make introduction of new capabilities, by those ASes that want to use them, harder because doing so requires other ASes (that may not be interested in the new capabilities) to upgrade their software". This difficulty potentially applies to each new capability that is introduced. The above examples are also covered by this definition, as would be the Secure BGP Attestation Path Attribute (to answer Mark's question above about real, proposed optional transitive attributes). [Truth in advertising disclaimer: if choice 1 (drop) were to be mandated, that would make the S-BGP implementation and policy configuration a LOT simpler.] What this really means, I would guess, is that the ASes that want to use new capabilities would simply form a bi-lateral peering agreement to bypass any ASes that do not want to support the new capabilities. (A "deploy from a single core outward" model instead of an "interconnected islands" aka "capability-bone" deployment model.) My opinion is that it would be better if the BGP protocol didn't encourage even more peering sessions, or other "workarounds", because of a misfeature in its specification. Charlie Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA29282 for ; Fri, 16 Feb 2001 12:48:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 044A45DFDD; Fri, 16 Feb 2001 12:44:45 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9681C5DFDF; Fri, 16 Feb 2001 12:44:44 -0500 (EST) Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by segue.merit.edu (Postfix) with ESMTP id 9A96E5DFDD for ; Fri, 16 Feb 2001 12:44:38 -0500 (EST) Received: from monterey.pluris.com (monterey.pluris.com [172.16.50.17]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id JAA13119; Fri, 16 Feb 2001 09:44:32 -0800 (PST) Received: by monterey.pluris.com with Internet Mail Service (5.5.2650.21) id ; Fri, 16 Feb 2001 09:44:31 -0800 Message-ID: From: Vivek Menezes To: "'Enke Chen'" Cc: Yakov Rekhter , "'idr@merit.edu'" Subject: RE: handling unrecognized optional transitive attributes Date: Fri, 16 Feb 2001 09:44:31 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idr@merit.edu Precedence: bulk Well said Enke. It looks like BGP implementations that have been deployed (Cisco et al) work very different from the RFC. Maybe Yakov you might consider changing the RFC to make it more relevant. There are a lot of people out there (in this discussion group, especially from the academic community) who assume that implementations are similar to the RFC. If the RFC is not inline with whats deployed their input would not be valuable and improvements to BGP would only be restricted to people working at router vendors. Cheers, Vivek. -----Original Message----- From: Enke Chen [mailto:enke@redback.com] Sent: Thursday, February 15, 2001 7:32 PM To: Charles Lynn Cc: Yakov Rekhter; idr@merit.edu Subject: Re: handling unrecognized optional transitive attributes > Date: Thu, 15 Feb 2001 21:57:27 +0500 (EST) > From: Charles Lynn > To: Yakov Rekhter > Cc: idr@merit.edu > Subject: Re: handling unrecognized optional transitive attributes > Message-Id: <20010216030346.EEB4D5DD93@segue.merit.edu> > Sender: owner-idr@merit.edu > Precedence: bulk > > Re: handling of unknown optional transitive attributes by an aggregator > > I agree that the WG should specify how they should be handled, and I > think that: > > only aggregate routes with identical attributes, > setting the partial bit. > > is the best of the choices being discussed. The other alternatives > that have been suggested include: > 1) drop these attributes; > 2) pick one and ignore the others; and > 3) combinations/choices of the above. > > Consider what might happen with choice 1. If one were to try to > introduce a new attribute that carried semantics like > ATOMIC_AGGREGATE, incremental deployment would be difficult. There > are cases where dropping an attribute could lead to lost traffic or > route loops. As has been pointed out, a drop strategy will make > introduction of any improvements to BGP difficult. If we were at the initial BGP deployment stage, we could as well have a different pick. However, "Choice 1" has been deployed (although not specified) for many years. Whatever future extensions that do not consider this reality will have a huge transition issue. Also, it seems to me that the question of "what might happend with choice 1" has been answered for quite some time. The COMMUNITY attribute which is optional transitive was introduced and deployed (quite smoothly if I remember correctly). -- Enke > > With choice 2, the semantics of a new attribute could be attached to > NLRI to which they do not apply. Again, one might get dropped traffic > or route loops. > > Choice 3 is worse. With this choice the semantics of the aggregate > could not be known as the receiver would not know what choices the > aggregator made (when the partial bit is set). > > If any of rules 1, 2, or 3 were in place, could BGP be easily extended > to include new attributes with, say, semantics similar to MP-REACH-NLRI, > and have that functionality incrementally deployed throughout the net? > > For these reasons, the suggested rule of only aggregating routes with > identical attributes (and setting the partial bit) seems to be the > best choice. > > Note that, if the operators of an AS really need to aggregate routes > with unknown attributes, they will have a good argument to present to > its router vendors to explain why the new attribute should be > implemented. > > > Stepping back from the immediate question, the WG might want to > consider a mechanism to address the problem of not knowing how to > aggregate unknown attributes. Yakov, Xavier, and Dima have commented > on per-attribute semantics. The WG could define a new attribute > flag(s) indicating how the attribute should be handled when a route > containing the attribute is a candidate for aggregation. The flag > technique has been used in other IETF protocols. The question of > whether the cost to implement such a mechanism would need to be > investigated. > > (For the record, I object to the proposal force speakers to drop > recognized optional transitive attributes from aggregated routes. :-) > > Charlie > Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA27846 for ; Fri, 16 Feb 2001 11:42:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id DF4F25DF4B; Fri, 16 Feb 2001 11:38:22 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 89B335DF4A; Fri, 16 Feb 2001 11:38:22 -0500 (EST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by segue.merit.edu (Postfix) with ESMTP id 290A75DF79 for ; Fri, 16 Feb 2001 11:38:07 -0500 (EST) Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id DF1CB4CFFD; Fri, 16 Feb 2001 11:37:35 -0500 (EST) Received: from research.att.com (griffin@castle7084.research.att.com [135.207.231.84]) by bigmail.research.att.com (8.8.8/8.8.8) with ESMTP id LAA02574; Fri, 16 Feb 2001 11:37:35 -0500 (EST) Message-ID: <3A8D4A16.C2E815D0@research.att.com> Date: Fri, 16 Feb 2001 10:41:10 -0500 From: tim griffin Reply-To: griffin@research.att.com Organization: at&t labs X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: "John G. Scudder" Cc: danny@ambernetworks.com, idr@merit.edu Subject: Re: BGP Route Oscillation References: <200101160121.SAA15311@tcb.net> <3A8C0E61.20BF31D0@research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk John, Thanks for your comments. >Many of the papers you cite talk about discovering incommensurable >policies, either statically or through protocol extensions. Since >the MED oscillation problem isn't a result of configured policy, I >don't see how such research can directly apply. > >In the MED oscillation case, you can get the oscillation even if >there is no configured policy at all. Thus I think it's a different >animal than the oscillation cases which have been covered in the >literature to date. Let's call the policies we type into a configuration file "apparent" routing policies, and call the dynamic ranking of routes that gets realized on a router the "actual" routing policies. The actual policies on a router result from a (sometimes complex) interaction of its apparent policies, the BGP route selection process, and the actual policies of neighboring routers. I think most of the papers on BGP oscillation are really about incommensurable *actual* policies, and so they do apply. In the MED oscillation examples routers end up with actual policies that together have no solution. Actual policies are in principle close to the function discussed in draft-ietf-idr-bgp4-12.txt, Section 9.1: The selection process is formalized by defining a function that takes the attribute of a given route as an argument and returns a non- negative integer denoting the degree of preference for the route. The function that calculates the degree of preference for a given route shall not use as its inputs any of the following: the existence of other routes, the non-existence of other routes, or the path attributes of other routes. Route selection then consists of individual application of the degree of preference function to each feasible route, followed by the choice of the one with the highest degree of preference. Perhaps MED is bad because it can make the translation from apparent to actual policies very hard to understand. MED is special in that it is not "compositional" like other steps in the route selection process. If we ignore MED, then we can think of ranking each route independently of other routes just as implied by the description of the ranking function in Section 9.1 quoted above. That is, we can think of the selection process as imposing some sort of simple lexical order on routes. But MED breaks this nice model, since its rule is conditional -- compare MEDs only when the next hop ASNs are the same. Now actual policies are no longer simple and intuitive rankings of paths. A route's rank can now depend on the existence, or non-existence of other routes. But isn't this the kind of ranking that is explicitly prohibited in Section 9.1? If so, why is it allowed in the Phase 2 tie breaking? I have always assumed that prohibition of "existential criteria" was there so that human beings could understand (and debug) the actual routing policies that result from their apparent ones. A simple fix might be to eliminate the MED step entirely, and add the MED value to the igp cost of a route. I realize this will cause other problems. However, it is easy to understand and may cover most of the current uses of MED just fine. It would require more cooperation between those sending and those listening to MEDs, which might not be a bad thing. > [...] The difference is that it is at least >possible to fix the policies so as to eliminate the oscillation -- >i.e., you can view the incommensurable policies as a case of >misconfiguration. I'm not sure that incommensurable policies will *always* be the result of misconfiguration. That is, I can't rule out a scenario where 1) everyone involved is doing something locally sane, 2) the interaction of the local policies result in protocol oscillation 3) no one is willing to budge (change their policies). Every AS involved is convinced that the others are at fault. Cheers, Tim Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA27436 for ; Fri, 16 Feb 2001 11:20:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id A01085DEE7; Fri, 16 Feb 2001 11:17:23 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 864D45DEED; Fri, 16 Feb 2001 11:17:23 -0500 (EST) Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id A5FA35DEE7 for ; Fri, 16 Feb 2001 11:17:21 -0500 (EST) Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id JAA01843 for ; Fri, 16 Feb 2001 09:16:13 -0700 Message-Id: <200102161616.JAA01843@tcb.net> X-Mailer: exmh version 2.0.3 To: "'idr@merit.edu'" From: Danny McPherson Reply-To: danny@ambernetworks.com Subject: Re: handling unrecognized optional transitive attributes Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Feb 2001 09:16:13 -0700 Sender: owner-idr@merit.edu Precedence: bulk I registered my opinion in messages prior to this one. Clearly, it's not a good thing, but I do agree that you have to draw the line somewhere between complexity and flexibility. -danny > By dropping new "unknown" optional transitive attributes you make it very > difficult to phase in > new attributes as the BGP protocol continues to evolve. Is this a good > thing? Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA26932 for ; Fri, 16 Feb 2001 10:58:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 36B195DEA0; Fri, 16 Feb 2001 10:56:58 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1F6A05DEA9; Fri, 16 Feb 2001 10:56:58 -0500 (EST) Received: from merlin.prod.itd.earthlink.net (merlin.prod.itd.earthlink.net [207.217.120.156]) by segue.merit.edu (Postfix) with ESMTP id C45D15DEA0 for ; Fri, 16 Feb 2001 10:56:49 -0500 (EST) Received: from optic3.ipoptical.com (dialup-166.90.26.179.Washington1.Level3.net [166.90.26.179]) by merlin.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with ESMTP id HAA26499; Fri, 16 Feb 2001 07:56:42 -0800 (PST) Received: by optic3.ipoptical.com with Internet Mail Service (5.5.2653.19) id <108STXV9>; Fri, 16 Feb 2001 10:54:13 -0500 Message-ID: From: Ben Abarbanel To: "'danny@ambernetworks.com'" , "'idr@merit.edu'" Subject: RE: handling unrecognized optional transitive attributes Date: Fri, 16 Feb 2001 10:54:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idr@merit.edu Precedence: bulk By dropping new "unknown" optional transitive attributes you make it very difficult to phase in new attributes as the BGP protocol continues to evolve. Is this a good thing? Ben -----Original Message----- From: owner-idr@merit.edu [mailto:owner-idr@merit.edu]On Behalf Of Danny McPherson Sent: Thursday, February 15, 2001 12:18 PM To: idr@merit.edu Subject: Re: handling unrecognized optional transitive attributes > I think, is not realistic since it would > lead to potentially different requirements for > different attributes. Yeah, this is my biggest problem with any alternative as well. -danny Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA23002 for ; Fri, 16 Feb 2001 08:13:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4B3B35DD90; Fri, 16 Feb 2001 08:12:36 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 24D305DEAF; Fri, 16 Feb 2001 08:12:36 -0500 (EST) Received: from oak.ggn.net (oak.ggn.net [198.207.193.5]) by segue.merit.edu (Postfix) with SMTP id 924CB5DD90 for ; Fri, 16 Feb 2001 08:12:34 -0500 (EST) Received: (qmail 11104 invoked by user marklist) by oak.ggn.net; 16 Feb 2001 13:12:33 -0000 Date: Fri, 16 Feb 2001 08:12:33 -0500 (EST) From: Mark Mentovai To: Dmitri Krioukov Cc: Charles Lynn , IDR Subject: RE: handling unrecognized optional transitive attributes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk Dmitri Krioukov wrote: >It's hard to imagine an optional transitive attribute with >semantics similar to ATOMIC_AGGREGATE, while it's easier, >I think, to imagine an optional transitive attribute with >semantics such that even if all routes being aggregated >have the identical value of this attribute, the attribute >value for the aggregated route is not supposed to be the same. It's hard to imagine, period. Let's consider some real optional transitive attributes. I've already covered the case of AGGREGATOR. COMMUNITIES is a no-brainer (to me, anyway.) The proposed NEW_AS_PATH and NEW_AGGREGATOR also don't seem to pose a problem. Are there any (real, not imaginary) used or proposed optional transitive attributes that would break under the "copy if all identical, else drop" scheme under discussion? Mark Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA13776 for ; Thu, 15 Feb 2001 23:39:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id C80485DEC8; Thu, 15 Feb 2001 23:35:31 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 688105DEBA; Thu, 15 Feb 2001 23:35:30 -0500 (EST) Received: from mail.krioukov.net (cj114416-a.reston1.va.home.com [24.15.191.36]) by segue.merit.edu (Postfix) with ESMTP id E61F95DDA6 for ; Thu, 15 Feb 2001 23:33:56 -0500 (EST) Received: from DIMA1 (dhcp-host-017.cj114416-a.reston1.va.home.com [192.168.1.17]) by mail.krioukov.net (8.9.3/8.9.3) with SMTP id XAA04594; Thu, 15 Feb 2001 23:33:48 -0500 From: "Dmitri Krioukov" To: "Charles Lynn" Cc: Subject: RE: handling unrecognized optional transitive attributes Date: Thu, 15 Feb 2001 23:33:49 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <20010216030346.EEB4D5DD93@segue.merit.edu> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-idr@merit.edu Precedence: bulk It's hard to imagine an optional transitive attribute with semantics similar to ATOMIC_AGGREGATE, while it's easier, I think, to imagine an optional transitive attribute with semantics such that even if all routes being aggregated have the identical value of this attribute, the attribute value for the aggregated route is not supposed to be the same. -- dima. > -----Original Message----- > From: owner-idr@merit.edu [mailto:owner-idr@merit.edu]On Behalf Of > Charles Lynn > Sent: Thursday, February 15, 2001 11:57 AM > To: Yakov Rekhter > Cc: idr@merit.edu > Subject: Re: handling unrecognized optional transitive attributes > > > Re: handling of unknown optional transitive attributes by an aggregator > > I agree that the WG should specify how they should be handled, and I > think that: > > only aggregate routes with identical attributes, > setting the partial bit. > > is the best of the choices being discussed. The other alternatives > that have been suggested include: > 1) drop these attributes; > 2) pick one and ignore the others; and > 3) combinations/choices of the above. > > Consider what might happen with choice 1. If one were to try to > introduce a new attribute that carried semantics like > ATOMIC_AGGREGATE, incremental deployment would be difficult. There > are cases where dropping an attribute could lead to lost traffic or > route loops. As has been pointed out, a drop strategy will make > introduction of any improvements to BGP difficult. > > With choice 2, the semantics of a new attribute could be attached to > NLRI to which they do not apply. Again, one might get dropped traffic > or route loops. > > Choice 3 is worse. With this choice the semantics of the aggregate > could not be known as the receiver would not know what choices the > aggregator made (when the partial bit is set). > > If any of rules 1, 2, or 3 were in place, could BGP be easily extended > to include new attributes with, say, semantics similar to MP-REACH-NLRI, > and have that functionality incrementally deployed throughout the net? > > For these reasons, the suggested rule of only aggregating routes with > identical attributes (and setting the partial bit) seems to be the > best choice. > > Note that, if the operators of an AS really need to aggregate routes > with unknown attributes, they will have a good argument to present to > its router vendors to explain why the new attribute should be > implemented. > > > Stepping back from the immediate question, the WG might want to > consider a mechanism to address the problem of not knowing how to > aggregate unknown attributes. Yakov, Xavier, and Dima have commented > on per-attribute semantics. The WG could define a new attribute > flag(s) indicating how the attribute should be handled when a route > containing the attribute is a candidate for aggregation. The flag > technique has been used in other IETF protocols. The question of > whether the cost to implement such a mechanism would need to be > investigated. > > (For the record, I object to the proposal force speakers to drop > recognized optional transitive attributes from aggregated routes. :-) > > Charlie Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA13319 for ; Thu, 15 Feb 2001 23:07:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id A02405DDC1; Thu, 15 Feb 2001 23:07:09 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9099F5DDA6; Thu, 15 Feb 2001 23:07:09 -0500 (EST) Received: from tower.partan.com (tower.partan.com [198.6.255.248]) by segue.merit.edu (Postfix) with ESMTP id D53815DD8C for ; Thu, 15 Feb 2001 23:07:06 -0500 (EST) Received: (from asp@localhost) by tower.partan.com (8.9.3/8.9.3) id XAA08332; Thu, 15 Feb 2001 23:06:57 -0500 (EST) Date: Thu, 15 Feb 2001 23:06:57 -0500 From: Andrew Partan To: Enke Chen Cc: Charles Lynn , Yakov Rekhter , idr@merit.edu Subject: Re: handling unrecognized optional transitive attributes Message-ID: <20010215230657.A8282@partan.com> References: <20010216033219.62A6C15D3C1@popserv.redback.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20010216033219.62A6C15D3C1@popserv.redback.com>; from enke@redback.com on Thu, Feb 15, 2001 at 07:32:19PM -0800 Sender: owner-idr@merit.edu Precedence: bulk On Thu, Feb 15, 2001 at 07:32:19PM -0800, Enke Chen wrote: > If we were at the initial BGP deployment stage, we could as well have > a different pick. However, "Choice 1" has been deployed (although not > specified) for many years. Whatever future extensions that do not > consider this reality will have a huge transition issue. Rolling out changed s/w is fairly doable; most folks upgrade their s/w fairly often. Yes, this change will not get to everyone, but it should hit most of the net fairly quickly. > Also, it seems to me that the question of "what might happend with > choice 1" has been answered for quite some time. The COMMUNITY attribute > which is optional transitive was introduced and deployed (quite smoothly > if I remember correctly). Communities are there, but have you ever tried to get one sent from one side of the net to the other? They are fairly well blocked at AS borders. --asp Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA12769 for ; Thu, 15 Feb 2001 22:34:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 132585DE5B; Thu, 15 Feb 2001 22:32:26 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id F37545DE68; Thu, 15 Feb 2001 22:32:25 -0500 (EST) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by segue.merit.edu (Postfix) with ESMTP id 669D45DE5B for ; Thu, 15 Feb 2001 22:32:24 -0500 (EST) Received: from popserv.redback.com (popserv.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 0761D48F3F; Thu, 15 Feb 2001 19:32:23 -0800 (PST) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv.redback.com (Postfix) with ESMTP id 62A6C15D3C1; Thu, 15 Feb 2001 19:32:19 -0800 (PST) To: Charles Lynn Cc: Yakov Rekhter , idr@merit.edu Subject: Re: handling unrecognized optional transitive attributes In-Reply-To: Message from Charles Lynn of "Thu, 15 Feb 2001 21:57:27 +0500." <20010216030346.EEB4D5DD93@segue.merit.edu> Date: Thu, 15 Feb 2001 19:32:19 -0800 From: Enke Chen Message-Id: <20010216033219.62A6C15D3C1@popserv.redback.com> Sender: owner-idr@merit.edu Precedence: bulk > Date: Thu, 15 Feb 2001 21:57:27 +0500 (EST) > From: Charles Lynn > To: Yakov Rekhter > Cc: idr@merit.edu > Subject: Re: handling unrecognized optional transitive attributes > Message-Id: <20010216030346.EEB4D5DD93@segue.merit.edu> > Sender: owner-idr@merit.edu > Precedence: bulk > > Re: handling of unknown optional transitive attributes by an aggregator > > I agree that the WG should specify how they should be handled, and I > think that: > > only aggregate routes with identical attributes, > setting the partial bit. > > is the best of the choices being discussed. The other alternatives > that have been suggested include: > 1) drop these attributes; > 2) pick one and ignore the others; and > 3) combinations/choices of the above. > > Consider what might happen with choice 1. If one were to try to > introduce a new attribute that carried semantics like > ATOMIC_AGGREGATE, incremental deployment would be difficult. There > are cases where dropping an attribute could lead to lost traffic or > route loops. As has been pointed out, a drop strategy will make > introduction of any improvements to BGP difficult. If we were at the initial BGP deployment stage, we could as well have a different pick. However, "Choice 1" has been deployed (although not specified) for many years. Whatever future extensions that do not consider this reality will have a huge transition issue. Also, it seems to me that the question of "what might happend with choice 1" has been answered for quite some time. The COMMUNITY attribute which is optional transitive was introduced and deployed (quite smoothly if I remember correctly). -- Enke > > With choice 2, the semantics of a new attribute could be attached to > NLRI to which they do not apply. Again, one might get dropped traffic > or route loops. > > Choice 3 is worse. With this choice the semantics of the aggregate > could not be known as the receiver would not know what choices the > aggregator made (when the partial bit is set). > > If any of rules 1, 2, or 3 were in place, could BGP be easily extended > to include new attributes with, say, semantics similar to MP-REACH-NLRI, > and have that functionality incrementally deployed throughout the net? > > For these reasons, the suggested rule of only aggregating routes with > identical attributes (and setting the partial bit) seems to be the > best choice. > > Note that, if the operators of an AS really need to aggregate routes > with unknown attributes, they will have a good argument to present to > its router vendors to explain why the new attribute should be > implemented. > > > Stepping back from the immediate question, the WG might want to > consider a mechanism to address the problem of not knowing how to > aggregate unknown attributes. Yakov, Xavier, and Dima have commented > on per-attribute semantics. The WG could define a new attribute > flag(s) indicating how the attribute should be handled when a route > containing the attribute is a candidate for aggregation. The flag > technique has been used in other IETF protocols. The question of > whether the cost to implement such a mechanism would need to be > investigated. > > (For the record, I object to the proposal force speakers to drop > recognized optional transitive attributes from aggregated routes. :-) > > Charlie > Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA12366 for ; Thu, 15 Feb 2001 22:06:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 690935DD93; Thu, 15 Feb 2001 22:03:48 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 491F65DE1D; Thu, 15 Feb 2001 22:03:48 -0500 (EST) Received: from CLYNN.BBN.COM (CLynn.BBN.COM [128.89.1.209]) by segue.merit.edu (Postfix) with SMTP id EEB4D5DD93 for ; Thu, 15 Feb 2001 22:03:46 -0500 (EST) Date: Thu, 15 Feb 2001 21:57:27 +0500 (EST) From: Charles Lynn To: Yakov Rekhter Cc: idr@merit.edu Subject: Re: handling unrecognized optional transitive attributes Message-Id: <20010216030346.EEB4D5DD93@segue.merit.edu> Sender: owner-idr@merit.edu Precedence: bulk Re: handling of unknown optional transitive attributes by an aggregator I agree that the WG should specify how they should be handled, and I think that: only aggregate routes with identical attributes, setting the partial bit. is the best of the choices being discussed. The other alternatives that have been suggested include: 1) drop these attributes; 2) pick one and ignore the others; and 3) combinations/choices of the above. Consider what might happen with choice 1. If one were to try to introduce a new attribute that carried semantics like ATOMIC_AGGREGATE, incremental deployment would be difficult. There are cases where dropping an attribute could lead to lost traffic or route loops. As has been pointed out, a drop strategy will make introduction of any improvements to BGP difficult. With choice 2, the semantics of a new attribute could be attached to NLRI to which they do not apply. Again, one might get dropped traffic or route loops. Choice 3 is worse. With this choice the semantics of the aggregate could not be known as the receiver would not know what choices the aggregator made (when the partial bit is set). If any of rules 1, 2, or 3 were in place, could BGP be easily extended to include new attributes with, say, semantics similar to MP-REACH-NLRI, and have that functionality incrementally deployed throughout the net? For these reasons, the suggested rule of only aggregating routes with identical attributes (and setting the partial bit) seems to be the best choice. Note that, if the operators of an AS really need to aggregate routes with unknown attributes, they will have a good argument to present to its router vendors to explain why the new attribute should be implemented. Stepping back from the immediate question, the WG might want to consider a mechanism to address the problem of not knowing how to aggregate unknown attributes. Yakov, Xavier, and Dima have commented on per-attribute semantics. The WG could define a new attribute flag(s) indicating how the attribute should be handled when a route containing the attribute is a candidate for aggregation. The flag technique has been used in other IETF protocols. The question of whether the cost to implement such a mechanism would need to be investigated. (For the record, I object to the proposal force speakers to drop recognized optional transitive attributes from aggregated routes. :-) Charlie Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA04633 for ; Thu, 15 Feb 2001 14:36:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 278325DE7C; Thu, 15 Feb 2001 14:31:04 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 20F745DE6A; Thu, 15 Feb 2001 14:31:03 -0500 (EST) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by segue.merit.edu (Postfix) with ESMTP id F14115DE7B for ; Thu, 15 Feb 2001 14:30:48 -0500 (EST) Received: from popserv.redback.com (popserv.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 28722B76793; Thu, 15 Feb 2001 11:30:47 -0800 (PST) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv.redback.com (Postfix) with ESMTP id D58B315D3C1; Thu, 15 Feb 2001 11:30:46 -0800 (PST) To: Yakov Rekhter Cc: "Dmitri Krioukov" , idr@merit.edu Subject: Re: handling unrecognized optional transitive attributes In-Reply-To: Message from Yakov Rekhter of "Thu, 15 Feb 2001 09:31:11 PST." <200102151731.JAA75945@garnet.juniper.net> Date: Thu, 15 Feb 2001 11:30:46 -0800 From: Enke Chen Message-Id: <20010215193046.D58B315D3C1@popserv.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Yakov, Another data pointer: I belive that the deployed base operates on the "dropping" model for "unrecognized transitive attributes" in aggregation, which might present another huddle for any alternative. -- Enke > Message-Id: <200102151731.JAA75945@garnet.juniper.net> > To: "Dmitri Krioukov" > Cc: idr@merit.edu > Subject: Re: handling unrecognized optional transitive attributes > In-Reply-To: Your message of "Thu, 15 Feb 2001 12:15:47 EST." > > MIME-Version: 1.0 > Content-Type: text/plain; charset="us-ascii" > Content-ID: <75942.982258271.1@garnet.juniper.net> > Date: Thu, 15 Feb 2001 09:31:11 -0800 > From: Yakov Rekhter > Sender: owner-idr@merit.edu > Precedence: bulk > > Dima, > > > I'd say that the discussion of the AGGREGATOR > > example suggests "MUST drop" unless you want > > to depend on semantics of a given attribute, > > which, I think, is not realistic since it would > > lead to potentially different requirements for > > different attributes. > > Even more important, since the BGP speaker doesn't recognize the > attribute, handling of this attribute by the speaker can't depend > on the semantics of this attribute (as handling of this attribute > based on the semantics assumes that the speaker knows the semantics > of this attribute, and therefore assumes that the speaker recognizes it, > which contradicts the premise that the speaker doesn't recognize it). > > Yakov. > > > -- > > dima. > > > > > -----Original Message----- > > > From: owner-idr@merit.edu [mailto:owner-idr@merit.edu]On Behalf Of Danny > > > McPherson > > > Sent: Thursday, February 15, 2001 11:15 AM > > > To: idr@merit.edu > > > Subject: Re: handling unrecognized optional transitive attributes > > > > > > > > > > > > > So, let's say that out of three routes to be aggregate two > > > > routes contain an unrecognized optional transitive attribute. > > > > What would you expect happen in this case ? > > > > > > Based on the wording I provided a moment ago .. drop it. If all > > > three contain the unrecognized optional transitive attribute > > > then the attribute MUST (or SHOULD?) be passed along to other > > > BGP peers and the Partial bit set to 1. > > > > > > While I agree with you in general, dropping the attribute just > > > doesn't make sense to me if ALL the subsets of a given aggregate > > > contain an identical optional transitive attribute. > > > > > > Of course, this model is a bit more complex, especially when one > > > considers what now needs to be done if the value of that one more- > > > specific's optional transitive attribute changes (be it in either > > > case) .. as such, I don't have _strong feelings either way. > > > > > > -danny > > > > > > Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA03261 for ; Thu, 15 Feb 2001 13:23:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0F4D05DF1A; Thu, 15 Feb 2001 13:21:13 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EA8235DF18; Thu, 15 Feb 2001 13:21:12 -0500 (EST) Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id DCA8D5DE6D for ; Thu, 15 Feb 2001 13:21:10 -0500 (EST) Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id LAA28408 for ; Thu, 15 Feb 2001 11:20:03 -0700 Message-Id: <200102151820.LAA28408@tcb.net> X-Mailer: exmh version 2.0.3 To: idr@merit.edu From: Danny McPherson Reply-To: danny@ambernetworks.com Subject: Re: BGP Route Oscillation Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 Feb 2001 11:20:03 -0700 Sender: owner-idr@merit.edu Precedence: bulk Thanks for the pointers Tim, I'm sure many will find them interesting. JSYK, the next version of the draft do indeed talk more about the general problem here. Obviously, once it's submitted your feedback regarding additional clarifications is welcome. -danny > It may help to identify the root cause of the > oscillation problem. To me the problem is inherent in > the way BGP works --- locally defined routing policies may > conflict globally, and certain types of conflicts can > cause persistent oscillation of the protocol. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA03045 for ; Thu, 15 Feb 2001 13:11:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id BDCC65DDDF; Thu, 15 Feb 2001 13:10:33 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id AC7945DDC5; Thu, 15 Feb 2001 13:10:33 -0500 (EST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by segue.merit.edu (Postfix) with ESMTP id 3D15A5DDA5 for ; Thu, 15 Feb 2001 13:10:32 -0500 (EST) Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id B81054CE6A; Thu, 15 Feb 2001 13:10:31 -0500 (EST) Received: from research.att.com (griffin@castle7084.research.att.com [135.207.231.84]) by bigmail.research.att.com (8.8.8/8.8.8) with ESMTP id NAA19487; Thu, 15 Feb 2001 13:10:30 -0500 (EST) Message-ID: <3A8C0E61.20BF31D0@research.att.com> Date: Thu, 15 Feb 2001 12:14:09 -0500 From: tim griffin Reply-To: griffin@research.att.com Organization: at&t labs X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: danny@ambernetworks.com, idr@merit.edu Subject: Re: BGP Route Oscillation References: <200101160121.SAA15311@tcb.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk draft-mcpherson-bgp-route-oscillation-00.txt states (page 15) : >> It should be stated that protocol enhancements regarding this problem >> must be pursued. Imposing network design requirements such as those >> outlined above are clearly an unreasonable long-term solution. Prob- >> lems such as this should not occur under 'default' configurations. It may help to identify the root cause of the oscillation problem. To me the problem is inherent in the way BGP works --- locally defined routing policies may conflict globally, and certain types of conflicts can cause persistent oscillation of the protocol. Given current practices, we happen to see the problem manifest itself in the context of MED + route reflectors or confederations. But simple examples can be constructed using only e-BGP and local pref. Although these examples currently don't seem to arise in practice, one can imagine that in the future they could in any number of ways (say a fancy use of extended communities to implement interdomain traffic engineering or QoS routing). Perhaps a generic mechanism is required to detect protocol oscillations dynamically. I've attached a list of recent research papers concerned with BGP persistent oscillation. I hope these will be useful. Paper [5] does define a mechanism for dynamic detection of protocol oscillation, but I'll be the first to admit that it does this only for an idealized version of BGP and that it is not yet clear if this model could serve as a basis for a practical extension to real world BGP. Tim Griffin griffin@research.att.com http://www.research.att.com/~griffin --------------------------------------------------------------- Recent research papers on BGP persistent oscillation. --------------------------------------------------------------- [1] Persistent Route Oscillations in Inter-Domain Routing. Kannan Varadhan, Ramesh Govindan, and Deborah Estrin. Computer Networks, Jan. 2000. http://www.elsevier.nl/gej-ng/10/15/22/45/25/27/article.pdf Also USC Tech Report CS TR 96-631, Feb. 1996, Department of Computer Science, University of Southern California. This was the first article to point out that fact that conflicting routing policies may cause persistent oscillations with BGP. Examples can be constructed using only e-BGP and local preference. [2] An Architecture for Stable, Analyzable Internet Routing. Ramesh Govindan, Cengiz Alaettinoglu, George Eddy, David Kessens, Satish Kumar, and WeeSan Lee. IEEE Network Magazine, Jan-Feb 1999. ftp://ftp.isi.edu/pub/govindan/ieeeNetwork99.ps.gz. Describes the router registries (IRR) and a language for defining interdomain routing policies (RPSL). As does [1], proposes that BGP persistent oscillation can be avoided by analysis of stored routing policies. [3] An Analysis of BGP Convergence Properties. Timothy G. Griffin and Gordon Wilfong. SIGCOMM 1999 http://www.acm.org/sigcomm/sigcomm99/papers/session8-1.html. Shows that the type of static analysis of routing policies suggested in [1][2] is NP-complete. [4] Policy Disputes in Path Vector Protocols. Timothy G. Griffin, F. Bruce Shepherd, and Gordon Wilfong. ICNP'99. http://www.research.att.com/~griffin/icnp1999.html. [5] A Safe Path Vector Protocol. Timothy G. Griffin and Gordon Wilfong. INFOCOM 2000. http://www.ieee-infocom.org/2000/papers/99.ps. Papers [4] and [5] introduce a simple model, called the Stable Paths Problem (SPP), that is to BGP what the Shortest Paths Problem is to OSPF and RIP. They also define a Simple Path Vector Protocol (SPVP), and idealized BGP-like protocol that attempts to solve an instances of the SPP. A sufficient condition is given that guarantees that an instance of SPP has a unique solution and that the SPVP protocol will always converge. [5] introduces an extension to to SPVP that dynamically detects persistent oscillations. More work is needed to determine if this could be the basis of a practical extension to BGP. See also the NANOG talk, http://www.nanog.org/mtg-0002/griffin.html [6] Stable Internet routing without global coordination. Lixin Gao and Jennifer Rexford. SIGMETRICS 2000. http://www.research.att.com/~jrex/papers/sigmetrics00.ps. Shows that if all ASes have customer/provider and peer/peer relationships, and all routing is based on preferring customers over peers and providers, then BGP will not diverge if there are no customer/provider cycles. In other words, current practices seem to go a long way in explaining why we do not see interdomain persistent oscillations. [7] Inherently Safe Backup Routing with BGP. Lixin Gao, Timothy G. Griffin, and Jennifer Rexford. to appear at INFOCOM 2001. http://www.research.att.com/~jrex/papers/infocom01.ps. Uses the theoretical framework of [4][5] to extend the results of [6] to include backup routing similar to that outlined in RFC 1998. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA02666 for ; Thu, 15 Feb 2001 12:52:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id EA7395DF7F; Thu, 15 Feb 2001 12:48:30 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A00555DF8D; Thu, 15 Feb 2001 12:48:30 -0500 (EST) Received: from tenornetworks.com (rtu.tenornetworks.com [63.77.213.2]) by segue.merit.edu (Postfix) with ESMTP id 53A7B5DF7F for ; Thu, 15 Feb 2001 12:48:11 -0500 (EST) Received: from tenornetworks.com (kavi [192.168.0.173]) by tenornetworks.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f1FHljV28584; Thu, 15 Feb 2001 12:47:45 -0500 (EST) Message-ID: <3A8C1546.2125FD7A@tenornetworks.com> Date: Thu, 15 Feb 2001 12:43:34 -0500 From: Xavier Briard Organization: Tenor Networks X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: danny@ambernetworks.com Cc: idr@merit.edu Subject: Re: handling unrecognized optional transitive attributes References: <200102151703.KAA27503@tcb.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk > I see, you want an "Optional [transitive] attribute" .. sounds > familiar. Then you're back to the same problem of what to do when > it's unrecognized or and/or only present in a subset of the routes > that comprise the aggregate. Not exactly. I meant more some aggregation rules LOCALLY configurable PER code type (this code type being a LOCALLY unrecognized optional attribute). The foundation of those STANDARD rules could look like: - rule 0 (default): drop - rule 1: drop unless all subsets present the EXACT same attribute value - rule 2: extend BGP path attribute encoding to find a way to concatenate all values... BTW, in all cases (except 0) set the partial bit. > The general goal, and presumably, the reason it was asked, was to keep > things as simple as possible while providing as much flexibility as > possible. > Agreed. "always dropping" is simple and does not require to monitor if the value of any subset happens to change over the life time of the aggregated route. The solution suggested above is fully flexible. It's almost a new feature: "aggregating rules for unrecognized optional transitive". It can help deployement of new such attributes. But is it worth it? not sure! BTW leaving the thread. Xavier Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA02001 for ; Thu, 15 Feb 2001 12:34:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2C6FD5DE7A; Thu, 15 Feb 2001 12:31:14 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1B9615DDDF; Thu, 15 Feb 2001 12:31:14 -0500 (EST) Received: from red.juniper.net (red.juniper.net [207.17.136.137]) by segue.merit.edu (Postfix) with ESMTP id 656F05DE78 for ; Thu, 15 Feb 2001 12:31:12 -0500 (EST) Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id JAA20264; Thu, 15 Feb 2001 09:31:11 -0800 (PST) Received: from garnet.juniper.net (localhost [127.0.0.1]) by garnet.juniper.net (8.9.3/8.9.3) with ESMTP id JAA75945; Thu, 15 Feb 2001 09:31:11 -0800 (PST) (envelope-from yakov@garnet.juniper.net) Message-Id: <200102151731.JAA75945@garnet.juniper.net> To: "Dmitri Krioukov" Cc: idr@merit.edu Subject: Re: handling unrecognized optional transitive attributes In-Reply-To: Your message of "Thu, 15 Feb 2001 12:15:47 EST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <75942.982258271.1@garnet.juniper.net> Date: Thu, 15 Feb 2001 09:31:11 -0800 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Dima, > I'd say that the discussion of the AGGREGATOR > example suggests "MUST drop" unless you want > to depend on semantics of a given attribute, > which, I think, is not realistic since it would > lead to potentially different requirements for > different attributes. Even more important, since the BGP speaker doesn't recognize the attribute, handling of this attribute by the speaker can't depend on the semantics of this attribute (as handling of this attribute based on the semantics assumes that the speaker knows the semantics of this attribute, and therefore assumes that the speaker recognizes it, which contradicts the premise that the speaker doesn't recognize it). Yakov. > -- > dima. > > > -----Original Message----- > > From: owner-idr@merit.edu [mailto:owner-idr@merit.edu]On Behalf Of Danny > > McPherson > > Sent: Thursday, February 15, 2001 11:15 AM > > To: idr@merit.edu > > Subject: Re: handling unrecognized optional transitive attributes > > > > > > > > > So, let's say that out of three routes to be aggregate two > > > routes contain an unrecognized optional transitive attribute. > > > What would you expect happen in this case ? > > > > Based on the wording I provided a moment ago .. drop it. If all > > three contain the unrecognized optional transitive attribute > > then the attribute MUST (or SHOULD?) be passed along to other > > BGP peers and the Partial bit set to 1. > > > > While I agree with you in general, dropping the attribute just > > doesn't make sense to me if ALL the subsets of a given aggregate > > contain an identical optional transitive attribute. > > > > Of course, this model is a bit more complex, especially when one > > considers what now needs to be done if the value of that one more- > > specific's optional transitive attribute changes (be it in either > > case) .. as such, I don't have _strong feelings either way. > > > > -danny > > > Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA01511 for ; Thu, 15 Feb 2001 12:22:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id D59915DEEB; Thu, 15 Feb 2001 12:19:20 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BE1095DEE4; Thu, 15 Feb 2001 12:19:20 -0500 (EST) Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id 84C3E5DEE0 for ; Thu, 15 Feb 2001 12:19:17 -0500 (EST) Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id KAA27620 for ; Thu, 15 Feb 2001 10:18:09 -0700 Message-Id: <200102151718.KAA27620@tcb.net> X-Mailer: exmh version 2.0.3 To: idr@merit.edu From: Danny McPherson Reply-To: danny@ambernetworks.com Subject: Re: handling unrecognized optional transitive attributes Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 Feb 2001 10:18:09 -0700 Sender: owner-idr@merit.edu Precedence: bulk > I think, is not realistic since it would > lead to potentially different requirements for > different attributes. Yeah, this is my biggest problem with any alternative as well. -danny Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA01451 for ; Thu, 15 Feb 2001 12:19:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5E88D5DE6C; Thu, 15 Feb 2001 12:15:55 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4A53D5DE5B; Thu, 15 Feb 2001 12:15:55 -0500 (EST) Received: from mail.krioukov.net (cj114416-a.reston1.va.home.com [24.15.191.36]) by segue.merit.edu (Postfix) with ESMTP id 51F3E5DDDF for ; Thu, 15 Feb 2001 12:15:53 -0500 (EST) Received: from DIMA1 (dhcp-host-017.cj114416-a.reston1.va.home.com [192.168.1.17]) by mail.krioukov.net (8.9.3/8.9.3) with SMTP id MAA03908; Thu, 15 Feb 2001 12:15:46 -0500 From: "Dmitri Krioukov" To: Cc: Subject: RE: handling unrecognized optional transitive attributes Date: Thu, 15 Feb 2001 12:15:47 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <200102151615.JAA27026@tcb.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-idr@merit.edu Precedence: bulk I'd say that the discussion of the AGGREGATOR example suggests "MUST drop" unless you want to depend on semantics of a given attribute, which, I think, is not realistic since it would lead to potentially different requirements for different attributes. -- dima. > -----Original Message----- > From: owner-idr@merit.edu [mailto:owner-idr@merit.edu]On Behalf Of Danny > McPherson > Sent: Thursday, February 15, 2001 11:15 AM > To: idr@merit.edu > Subject: Re: handling unrecognized optional transitive attributes > > > > > So, let's say that out of three routes to be aggregate two > > routes contain an unrecognized optional transitive attribute. > > What would you expect happen in this case ? > > Based on the wording I provided a moment ago .. drop it. If all > three contain the unrecognized optional transitive attribute > then the attribute MUST (or SHOULD?) be passed along to other > BGP peers and the Partial bit set to 1. > > While I agree with you in general, dropping the attribute just > doesn't make sense to me if ALL the subsets of a given aggregate > contain an identical optional transitive attribute. > > Of course, this model is a bit more complex, especially when one > considers what now needs to be done if the value of that one more- > specific's optional transitive attribute changes (be it in either > case) .. as such, I don't have _strong feelings either way. > > -danny > Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA01191 for ; Thu, 15 Feb 2001 12:06:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id EB8B25DEAC; Thu, 15 Feb 2001 12:04:38 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DA5175DEA9; Thu, 15 Feb 2001 12:04:38 -0500 (EST) Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id ED5485DE9A for ; Thu, 15 Feb 2001 12:04:36 -0500 (EST) Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id KAA27503 for ; Thu, 15 Feb 2001 10:03:29 -0700 Message-Id: <200102151703.KAA27503@tcb.net> X-Mailer: exmh version 2.0.3 To: idr@merit.edu From: Danny McPherson Reply-To: danny@ambernetworks.com Subject: Re: handling unrecognized optional transitive attributes Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 Feb 2001 10:03:29 -0700 Sender: owner-idr@merit.edu Precedence: bulk > > While I agree with you in general, dropping the attribute just > > doesn't make sense to me if ALL the subsets of a given aggregate > > contain an identical optional transitive attribute. > > What exactly is the probability to receive an IDENTICAL optional > transitive attribute from ALL subsets? I guess nobody can really answer > this. But it COULD very well be a rare event (again depending on the > actual UNRECOGNIZED semantic of the attribute). OTOH, it could be much greater than one would suspect, as an optional transitive attribute doesn't 'just appear', there's going to be some reasoning as to why, and with that being the case, it's likely to appear in other places as well. > So why adding this complexity to help solving the issue in maybe less > than 10% of all possible cases? Because in the 10%, or even 1% of the areas that it arises, mods beforehand make things a lot simpler down the road. > If there really is an elaborated solution to help deployement of future > such attributes, why not make it elaborate enough to help in ALL > possible cases (like "to be defined" generic aggregation rules > configurable per type code)? I see, you want an "Optional [transitive] attribute" .. sounds familiar. Then you're back to the same problem of what to do when it's unrecognized or and/or only present in a subset of the routes that comprise the aggregate. The general goal, and presumably, the reason it was asked, was to keep things as simple as possible while providing as much flexibility as possible. -danny Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA00653 for ; Thu, 15 Feb 2001 11:48:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5D4B95DE66; Thu, 15 Feb 2001 11:45:25 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 47A6A5DE5C; Thu, 15 Feb 2001 11:45:25 -0500 (EST) Received: from tenornetworks.com (rtu.tenornetworks.com [63.77.213.2]) by segue.merit.edu (Postfix) with ESMTP id 621D95DE5B for ; Thu, 15 Feb 2001 11:45:23 -0500 (EST) Received: from tenornetworks.com (kavi [192.168.0.173]) by tenornetworks.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f1FGj4V23166; Thu, 15 Feb 2001 11:45:04 -0500 (EST) Message-ID: <3A8C06A6.541FE4B9@tenornetworks.com> Date: Thu, 15 Feb 2001 11:41:10 -0500 From: Xavier Briard Organization: Tenor Networks X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: danny@ambernetworks.com Cc: idr@merit.edu Subject: Re: handling unrecognized optional transitive attributes References: <200102151615.JAA27026@tcb.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk > While I agree with you in general, dropping the attribute just > doesn't make sense to me if ALL the subsets of a given aggregate > contain an identical optional transitive attribute. What exactly is the probability to receive an IDENTICAL optional transitive attribute from ALL subsets? I guess nobody can really answer this. But it COULD very well be a rare event (again depending on the actual UNRECOGNIZED semantic of the attribute). > Of course, this model is a bit more complex, especially when one > considers what now needs to be done if the value of that one more- > specific's optional transitive attribute changes (be it in either > case) .. as such, I don't have _strong feelings either way. So why adding this complexity to help solving the issue in maybe less than 10% of all possible cases? If there really is an elaborated solution to help deployement of future such attributes, why not make it elaborate enough to help in ALL possible cases (like "to be defined" generic aggregation rules configurable per type code)? my $.02 Xavier Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA00027 for ; Thu, 15 Feb 2001 11:19:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id DD6D65DE86; Thu, 15 Feb 2001 11:16:20 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CC5525DE7B; Thu, 15 Feb 2001 11:16:20 -0500 (EST) Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id 4C8B65DE72 for ; Thu, 15 Feb 2001 11:16:18 -0500 (EST) Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id JAA27026 for ; Thu, 15 Feb 2001 09:15:10 -0700 Message-Id: <200102151615.JAA27026@tcb.net> X-Mailer: exmh version 2.0.3 To: idr@merit.edu From: Danny McPherson Reply-To: danny@ambernetworks.com Subject: Re: handling unrecognized optional transitive attributes Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 Feb 2001 09:15:10 -0700 Sender: owner-idr@merit.edu Precedence: bulk > So, let's say that out of three routes to be aggregate two > routes contain an unrecognized optional transitive attribute. > What would you expect happen in this case ? Based on the wording I provided a moment ago .. drop it. If all three contain the unrecognized optional transitive attribute then the attribute MUST (or SHOULD?) be passed along to other BGP peers and the Partial bit set to 1. While I agree with you in general, dropping the attribute just doesn't make sense to me if ALL the subsets of a given aggregate contain an identical optional transitive attribute. Of course, this model is a bit more complex, especially when one considers what now needs to be done if the value of that one more- specific's optional transitive attribute changes (be it in either case) .. as such, I don't have _strong feelings either way. -danny Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA28601 for ; Thu, 15 Feb 2001 10:49:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 01B675DE62; Thu, 15 Feb 2001 10:46:28 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DC8C05DE65; Thu, 15 Feb 2001 10:46:27 -0500 (EST) Received: from red.juniper.net (red.juniper.net [207.17.136.137]) by segue.merit.edu (Postfix) with ESMTP id D18AD5DE62 for ; Thu, 15 Feb 2001 10:46:25 -0500 (EST) Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id HAA12541; Thu, 15 Feb 2001 07:46:25 -0800 (PST) Received: from garnet.juniper.net (localhost [127.0.0.1]) by garnet.juniper.net (8.9.3/8.9.3) with ESMTP id HAA63163; Thu, 15 Feb 2001 07:46:25 -0800 (PST) (envelope-from yakov@garnet.juniper.net) Message-Id: <200102151546.HAA63163@garnet.juniper.net> To: Ben Abarbanel Cc: "'idr@merit.edu'" Subject: Re: handling unrecognized optional transitive attributes In-Reply-To: Your message of "Thu, 15 Feb 2001 10:38:49 EST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <63160.982251985.1@garnet.juniper.net> Date: Thu, 15 Feb 2001 07:46:25 -0800 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Ben, > If we drop the unrecognized optional transitive attribute we dont leave > the door open > for adding new features into BGP and thus make phasing new features a pain. > Can we not drop unknown attributes of all kinds? Do you have a specific proposal on how to deal with unrecognized optional transitive attributes when aggregating routes ? Yakov. > > Ben > > -----Original Message----- > From: owner-idr@merit.edu [mailto:owner-idr@merit.edu]On Behalf Of Yakov > Rekhter > Sent: Thursday, February 15, 2001 9:51 AM > To: Ben Abarbanel > Cc: 'idr@merit.edu' > Subject: Re: handling unrecognized optional transitive attributes > > > Ben, > > > Yakov: > > I thought optional transitive means the attribute is passed through > > without being dropped? > > Yes, that is what you do if you don't aggregate routes. The issue > I brought up is what to do when you aggregate routes. > > Yakov. > > > > Ben > > > > -----Original Message----- > > From: owner-idr@merit.edu [mailto:owner-idr@merit.edu]On Behalf Of Yakov > > Rekhter > > Sent: Wednesday, February 14, 2001 8:57 AM > > To: idr@merit.edu > > Subject: handling unrecognized optional transitive attributes > > > > > > Folks, > > > > The current BGP spec doesn't say anything wrt how a BGP speaker > > that aggregates several routes should handle optional transitive > > attributes of these routes if the speaker doesn't recognize the > > attributes. We should probably need to specify how to handle this. > > One option would be to require the speaker to drop these attributes. > > Any other (reasonable) options ? > > > > Yakov. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA28436 for ; Thu, 15 Feb 2001 10:42:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8A1835DE7F; Thu, 15 Feb 2001 10:41:33 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6F91B5DE7E; Thu, 15 Feb 2001 10:41:33 -0500 (EST) Received: from merlin.prod.itd.earthlink.net (merlin.prod.itd.earthlink.net [207.217.120.156]) by segue.merit.edu (Postfix) with ESMTP id 5680F5DE78 for ; Thu, 15 Feb 2001 10:41:18 -0500 (EST) Received: from optic3.ipoptical.com (dialup-166.90.26.179.Washington1.Level3.net [166.90.26.179]) by merlin.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with ESMTP id HAA22574; Thu, 15 Feb 2001 07:41:16 -0800 (PST) Received: by optic3.ipoptical.com with Internet Mail Service (5.5.2653.19) id <108STXQM>; Thu, 15 Feb 2001 10:38:50 -0500 Message-ID: From: Ben Abarbanel To: "'Yakov Rekhter'" , "'idr@merit.edu'" Subject: RE: handling unrecognized optional transitive attributes Date: Thu, 15 Feb 2001 10:38:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idr@merit.edu Precedence: bulk Yakov: If we drop the unrecognized optional transitive attribute we dont leave the door open for adding new features into BGP and thus make phasing new features a pain. Can we not drop unknown attributes of all kinds? Ben -----Original Message----- From: owner-idr@merit.edu [mailto:owner-idr@merit.edu]On Behalf Of Yakov Rekhter Sent: Thursday, February 15, 2001 9:51 AM To: Ben Abarbanel Cc: 'idr@merit.edu' Subject: Re: handling unrecognized optional transitive attributes Ben, > Yakov: > I thought optional transitive means the attribute is passed through > without being dropped? Yes, that is what you do if you don't aggregate routes. The issue I brought up is what to do when you aggregate routes. Yakov. > > Ben > > -----Original Message----- > From: owner-idr@merit.edu [mailto:owner-idr@merit.edu]On Behalf Of Yakov > Rekhter > Sent: Wednesday, February 14, 2001 8:57 AM > To: idr@merit.edu > Subject: handling unrecognized optional transitive attributes > > > Folks, > > The current BGP spec doesn't say anything wrt how a BGP speaker > that aggregates several routes should handle optional transitive > attributes of these routes if the speaker doesn't recognize the > attributes. We should probably need to specify how to handle this. > One option would be to require the speaker to drop these attributes. > Any other (reasonable) options ? > > Yakov. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA28401 for ; Thu, 15 Feb 2001 10:41:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 371585DE63; Thu, 15 Feb 2001 10:41:04 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 27F265DE5B; Thu, 15 Feb 2001 10:41:04 -0500 (EST) Received: from red.juniper.net (red.juniper.net [207.17.136.137]) by segue.merit.edu (Postfix) with ESMTP id 360015DE5C for ; Thu, 15 Feb 2001 10:41:02 -0500 (EST) Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id HAA12257; Thu, 15 Feb 2001 07:41:01 -0800 (PST) Received: from garnet.juniper.net (localhost [127.0.0.1]) by garnet.juniper.net (8.9.3/8.9.3) with ESMTP id HAA62434; Thu, 15 Feb 2001 07:41:01 -0800 (PST) (envelope-from yakov@garnet.juniper.net) Message-Id: <200102151541.HAA62434@garnet.juniper.net> To: danny@ambernetworks.com Cc: idr@merit.edu Subject: Re: handling unrecognized optional transitive attributes In-Reply-To: Your message of "Thu, 15 Feb 2001 08:33:07 MST." <200102151533.IAA26687@tcb.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <62431.982251661.1@garnet.juniper.net> Date: Thu, 15 Feb 2001 07:41:01 -0800 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Danny, > I'm OK with the general idea here, but I don't think > dropping the attribute(s) is necessary if ALL the routes > contain them. > > I'd be more appeased by wording that suggests "unless ALL > routes within an aggregate contain an unrecognized optional > transitive attribute, it MUST be dropped". > > IMO, this addresses the case sufficiently, but provides > some amount of flexibility as well. So, let's say that out of three routes to be aggregate two routes contain an unrecognized optional transitive attribute. What would you expect happen in this case ? Yakov. > > -danny > > > So, how about if we'll insert the following text at the end of > > 9.2.4.2: > > > > When a BGP speaker aggregates several routes, and some/all of > > these routes contain optional transitive attributes that are not > > recognized by the speaker, the speaker MUST drop these attributes > > from the aggregate route. > > > > If there are no objections to this before end of next week, I'll > > add this text to the Internet Draft and re-issue it. > > Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA28288 for ; Thu, 15 Feb 2001 10:37:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9B0325DE5D; Thu, 15 Feb 2001 10:34:17 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8857E5DE62; Thu, 15 Feb 2001 10:34:17 -0500 (EST) Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id 7F8065DE5D for ; Thu, 15 Feb 2001 10:34:15 -0500 (EST) Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id IAA26687 for ; Thu, 15 Feb 2001 08:33:07 -0700 Message-Id: <200102151533.IAA26687@tcb.net> X-Mailer: exmh version 2.0.3 To: idr@merit.edu From: Danny McPherson Reply-To: danny@ambernetworks.com Subject: Re: handling unrecognized optional transitive attributes Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 Feb 2001 08:33:07 -0700 Sender: owner-idr@merit.edu Precedence: bulk I'm OK with the general idea here, but I don't think dropping the attribute(s) is necessary if ALL the routes contain them. I'd be more appeased by wording that suggests "unless ALL routes within an aggregate contain an unrecognized optional transitive attribute, it MUST be dropped". IMO, this addresses the case sufficiently, but provides some amount of flexibility as well. -danny > So, how about if we'll insert the following text at the end of > 9.2.4.2: > > When a BGP speaker aggregates several routes, and some/all of > these routes contain optional transitive attributes that are not > recognized by the speaker, the speaker MUST drop these attributes > from the aggregate route. > > If there are no objections to this before end of next week, I'll > add this text to the Internet Draft and re-issue it. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA27351 for ; Thu, 15 Feb 2001 09:57:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 301715DE4F; Thu, 15 Feb 2001 09:57:11 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 20D555DE3F; Thu, 15 Feb 2001 09:57:11 -0500 (EST) Received: from red.juniper.net (red.juniper.net [207.17.136.137]) by segue.merit.edu (Postfix) with ESMTP id 66E9B5DE3E for ; Thu, 15 Feb 2001 09:57:09 -0500 (EST) Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id GAA09683; Thu, 15 Feb 2001 06:57:09 -0800 (PST) Received: from garnet.juniper.net (localhost [127.0.0.1]) by garnet.juniper.net (8.9.3/8.9.3) with ESMTP id GAA57101; Thu, 15 Feb 2001 06:57:08 -0800 (PST) (envelope-from yakov@garnet.juniper.net) Message-Id: <200102151457.GAA57101@garnet.juniper.net> To: Enke Chen Cc: idr@merit.edu Subject: Re: handling unrecognized optional transitive attributes In-Reply-To: Your message of "Wed, 14 Feb 2001 12:21:00 PST." <20010214202100.C990E979C2@popserv2.redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <57098.982249028.1@garnet.juniper.net> Date: Thu, 15 Feb 2001 06:57:08 -0800 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk > > Folks, > > > > The current BGP spec doesn't say anything wrt how a BGP speaker > > that aggregates several routes should handle optional transitive > > attributes of these routes if the speaker doesn't recognize the > > attributes. We should probably need to specify how to handle this. > > > One option would be to require the speaker to drop these attributes. > > This seems to be reasonable. I do not see much benefit (but more > complexity) in trying to keep the attribute during aggregation. So, how about if we'll insert the following text at the end of 9.2.4.2: When a BGP speaker aggregates several routes, and some/all of these routes contain optional transitive attributes that are not recognized by the speaker, the speaker MUST drop these attributes from the aggregate route. If there are no objections to this before end of next week, I'll add this text to the Internet Draft and re-issue it. Yakov. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA27260 for ; Thu, 15 Feb 2001 09:54:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 172965DE99; Thu, 15 Feb 2001 09:52:59 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E92595DEA9; Thu, 15 Feb 2001 09:52:58 -0500 (EST) Received: from oak.ggn.net (oak.ggn.net [198.207.193.5]) by segue.merit.edu (Postfix) with SMTP id 9E3FF5DE99 for ; Thu, 15 Feb 2001 09:52:55 -0500 (EST) Received: (qmail 13632 invoked by user marklist) by oak.ggn.net; 15 Feb 2001 14:52:54 -0000 Date: Thu, 15 Feb 2001 09:52:54 -0500 (EST) From: Mark Mentovai To: Xavier Briard Cc: Dmitri Krioukov , IDR Subject: Re: handling unrecognized optional transitive attributes In-Reply-To: <3A8AE274.B2714438@tenornetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk Xavier Briard wrote: >> > How about this: if all of the routes being aggregated contain identical >> > instances of the unknown optional transitive attribute in >> > question, the BGP >> > speaker should include the attribute in the aggregated route, with the >> > partial bit set, but may instead drop the attribute. >> >> Why not a hard choice here? > >Like "dropping" as suggested first. > >Let's take for example the AGGREGATOR attribute (optional transitive). >BGP spec says: >"All AGGREGATOR attributes of all routes to be aggragted should be >ignored" > >Let's now ASSUME a router not recognizing this attribute (allowed by >nature...). Applying a rule like keeping it if all sources present the >same value goes against the previous statement. "Should be ignored." But the attribute still makes sense, and still applies somewhat to the new aggregated prefixes, provided the AGGREGATOR attributes carried with the longer prefixes now being aggregated were identical. In this case, the speaker won't be adding a new AGGREGATOR, and others will see based on the partial bit that the data contained within the attribute isn't guaranteed to be 100% accurate. The aggregator listed in the AGGREGATOR attribute will still be -an- aggregator of the entire prefix, just not -the- aggregator of the new unified advertisement. I think it's better to retain the AGGREGATOR attribute in any case, regardless of the authenticity of the included aggregating AS and speaker, to inform others that the advertisement is the result of one (or more) aggregations. >One could argue in general that depending on the semantic of the >attribute it may not make sense at all to give a value to the aggregate >equal to the unique value of all sources (because a router supporting >this attribute would have computed the sum for example). This is what the partial bit is about. If any BGP speaker needs to be guaranteed that an optional transitive attribute requiring processing by other BGP speakers is correct, it has to check the partial bit. In this case, the partial bit would be set. The rationale I'm following is that it's better to provide more data than less data, by setting the partial bit, you can notify other BGP speakers that the attribute data may not be valid. Speakers which understand the attribute will know whether or not to trust data with the partial bit set. They may choose, for example, to honor a COMMUNITIES attribute even with the partial bit set, but ignore an attribute that requires a sum to be recomputed at each step unless the bit is clear. Why not a hard choice? Because I don't think one is warranted here - I recommend providing going the extra mile to provide the data if you desire, but if that's too much, the attribute can be dropped. Existing BGP speakers probably just drop unknown optional transitive attributes on aggregation anyway, and I don't think it's worth making them noncompliant over a point as minor as this. Still, I do see some value in trying to preserve as much of the initial advertisement as possible. Doesn't seem to be a very popular opinion, though. :) Mark Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA27240 for ; Thu, 15 Feb 2001 09:52:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id EC8555DDCF; Thu, 15 Feb 2001 09:50:54 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C80F85DE3E; Thu, 15 Feb 2001 09:50:54 -0500 (EST) Received: from red.juniper.net (red.juniper.net [207.17.136.137]) by segue.merit.edu (Postfix) with ESMTP id 135875DDCF for ; Thu, 15 Feb 2001 09:50:53 -0500 (EST) Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id GAA09487; Thu, 15 Feb 2001 06:50:52 -0800 (PST) Received: from garnet.juniper.net (localhost [127.0.0.1]) by garnet.juniper.net (8.9.3/8.9.3) with ESMTP id GAA56517; Thu, 15 Feb 2001 06:50:52 -0800 (PST) (envelope-from yakov@garnet.juniper.net) Message-Id: <200102151450.GAA56517@garnet.juniper.net> To: Ben Abarbanel Cc: "'idr@merit.edu'" Subject: Re: handling unrecognized optional transitive attributes In-Reply-To: Your message of "Wed, 14 Feb 2001 09:48:13 EST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <56514.982248652.1@garnet.juniper.net> Date: Thu, 15 Feb 2001 06:50:52 -0800 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Ben, > Yakov: > I thought optional transitive means the attribute is passed through > without being dropped? Yes, that is what you do if you don't aggregate routes. The issue I brought up is what to do when you aggregate routes. Yakov. > > Ben > > -----Original Message----- > From: owner-idr@merit.edu [mailto:owner-idr@merit.edu]On Behalf Of Yakov > Rekhter > Sent: Wednesday, February 14, 2001 8:57 AM > To: idr@merit.edu > Subject: handling unrecognized optional transitive attributes > > > Folks, > > The current BGP spec doesn't say anything wrt how a BGP speaker > that aggregates several routes should handle optional transitive > attributes of these routes if the speaker doesn't recognize the > attributes. We should probably need to specify how to handle this. > One option would be to require the speaker to drop these attributes. > Any other (reasonable) options ? > > Yakov. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA07478 for ; Wed, 14 Feb 2001 15:22:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0BC245DEBC; Wed, 14 Feb 2001 15:21:04 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id ECE7B5DEBB; Wed, 14 Feb 2001 15:21:03 -0500 (EST) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by segue.merit.edu (Postfix) with ESMTP id 76C8A5DE73 for ; Wed, 14 Feb 2001 15:21:02 -0500 (EST) Received: from popserv2.redback.com (popserv2.redback.com [155.53.12.59]) by prattle.redback.com (Postfix) with ESMTP id 18BDFB76788; Wed, 14 Feb 2001 12:21:01 -0800 (PST) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv2.redback.com (Postfix) with ESMTP id C990E979C2; Wed, 14 Feb 2001 12:21:00 -0800 (PST) To: Yakov Rekhter Cc: idr@merit.edu Subject: Re: handling unrecognized optional transitive attributes In-Reply-To: Message from Yakov Rekhter of "Wed, 14 Feb 2001 05:56:40 PST." <200102141356.FAA80509@garnet.juniper.net> Date: Wed, 14 Feb 2001 12:21:00 -0800 From: Enke Chen Message-Id: <20010214202100.C990E979C2@popserv2.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Yakov, > Message-Id: <200102141356.FAA80509@garnet.juniper.net> > To: idr@merit.edu > Subject: handling unrecognized optional transitive attributes > MIME-Version: 1.0 > Content-Type: text/plain; charset="us-ascii" > Content-ID: <80506.982159000.1@garnet.juniper.net> > Date: Wed, 14 Feb 2001 05:56:40 -0800 > From: Yakov Rekhter > Sender: owner-idr@merit.edu > Precedence: bulk > > Folks, > > The current BGP spec doesn't say anything wrt how a BGP speaker > that aggregates several routes should handle optional transitive > attributes of these routes if the speaker doesn't recognize the > attributes. We should probably need to specify how to handle this. > One option would be to require the speaker to drop these attributes. This seems to be reasonable. I do not see much benefit (but more complexity) in trying to keep the attribute during aggregation. -- Enke > Any other (reasonable) options ? > > Yakov. > Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA06895 for ; Wed, 14 Feb 2001 14:58:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6F0485DDAF; Wed, 14 Feb 2001 14:58:18 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5B4395DE04; Wed, 14 Feb 2001 14:58:18 -0500 (EST) Received: from tenornetworks.com (rtu.tenornetworks.com [63.77.213.2]) by segue.merit.edu (Postfix) with ESMTP id A05385DDAF for ; Wed, 14 Feb 2001 14:58:16 -0500 (EST) Received: from tenornetworks.com (kavi [192.168.0.173]) by tenornetworks.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f1EJwDJ04942; Wed, 14 Feb 2001 14:58:13 -0500 (EST) Message-ID: <3A8AE274.B2714438@tenornetworks.com> Date: Wed, 14 Feb 2001 14:54:28 -0500 From: Xavier Briard Organization: Tenor Networks X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Dmitri Krioukov Cc: Mark Mentovai , IDR Subject: Re: handling unrecognized optional transitive attributes References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk > > How about this: if all of the routes being aggregated contain identical > > instances of the unknown optional transitive attribute in > > question, the BGP > > speaker should include the attribute in the aggregated route, with the > > partial bit set, but may instead drop the attribute. > > Why not a hard choice here? Like "dropping" as suggested first. Let's take for example the AGGREGATOR attribute (optional transitive). BGP spec says: "All AGGREGATOR attributes of all routes to be aggragted should be ignored" Let's now ASSUME a router not recognizing this attribute (allowed by nature...). Applying a rule like keeping it if all sources present the same value goes against the previous statement. One could argue in general that depending on the semantic of the attribute it may not make sense at all to give a value to the aggregate equal to the unique value of all sources (because a router supporting this attribute would have computed the sum for example). Xavier Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA05684 for ; Wed, 14 Feb 2001 14:05:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 47CF55DE39; Wed, 14 Feb 2001 14:01:32 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2FF445DE6A; Wed, 14 Feb 2001 14:01:32 -0500 (EST) Received: from mail.krioukov.net (cj114416-a.reston1.va.home.com [24.15.191.36]) by segue.merit.edu (Postfix) with ESMTP id 982085DE39 for ; Wed, 14 Feb 2001 14:01:30 -0500 (EST) Received: from DIMA1 ([47.184.55.188]) by mail.krioukov.net (8.9.3/8.9.3) with SMTP id OAA02931; Wed, 14 Feb 2001 14:01:28 -0500 From: "Dmitri Krioukov" To: "Mark Mentovai" Cc: "IDR" Subject: RE: handling unrecognized optional transitive attributes Date: Wed, 14 Feb 2001 14:01:30 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-idr@merit.edu Precedence: bulk > -----Original Message----- > From: owner-idr@merit.edu [mailto:owner-idr@merit.edu]On Behalf Of Mark > Mentovai > Sent: Wednesday, February 14, 2001 10:49 AM > To: Yakov Rekhter > Cc: IDR > Subject: Re: handling unrecognized optional transitive attributes > > > Yakov Rekhter wrote: > >The current BGP spec doesn't say anything wrt how a BGP speaker > >that aggregates several routes should handle optional transitive > >attributes of these routes if the speaker doesn't recognize the > >attributes. We should probably need to specify how to handle this. > >One option would be to require the speaker to drop these attributes. > >Any other (reasonable) options ? > > How about this: if all of the routes being aggregated contain identical > instances of the unknown optional transitive attribute in > question, the BGP > speaker should include the attribute in the aggregated route, with the > partial bit set, but may instead drop the attribute. Why not a hard choice here? > If the routes being > aggregated don't all contain identical instances of the unknown attribute, > the attribute must not be included in the aggregated route. > > Does that sound sane? Sound like it'll break anything? > > Mark -- dima. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA05565 for ; Wed, 14 Feb 2001 13:58:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7823B5DE4A; Wed, 14 Feb 2001 13:54:15 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5D3F25DE3E; Wed, 14 Feb 2001 13:54:15 -0500 (EST) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by segue.merit.edu (Postfix) with ESMTP id DA5BF5DE66 for ; Wed, 14 Feb 2001 13:54:07 -0500 (EST) Received: from popserv3.redback.com (popserv3.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id C2F37B76790; Wed, 14 Feb 2001 10:54:04 -0800 (PST) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv3.redback.com (Postfix) with ESMTP id 9E7B07FF84; Wed, 14 Feb 2001 10:54:04 -0800 (PST) To: jtsillas@tenornetworks.com Cc: "IDR" , enke@redback.com Subject: Re: graceful restart question In-Reply-To: Message from "James Tsillas" of "Wed, 14 Feb 2001 13:37:16 EST." Date: Wed, 14 Feb 2001 10:54:04 -0800 From: Enke Chen Message-Id: <20010214185404.9E7B07FF84@popserv3.redback.com> Sender: owner-idr@merit.edu Precedence: bulk > Reply-To: > From: "James Tsillas" > To: "IDR" > Subject: graceful restart question > Date: Wed, 14 Feb 2001 13:37:16 -0500 > Message-ID: > > If the receiving speaker detected a TCP reset but the > received capability turns out not to have the restart flag > set (but did have the forwarding state bit set for some > AFs) is it correct for the receiving speaker to flush > stale routing information before the end-of-RIB is received? No. > Is the restart flag only considered by restarting speakers > to avoid deadlock or can it be used as an indication of > whether a given peer has really restarted? See the text in Sect 5. Graceful Restart Capability: When set (value 1), this bit indicates that the BGP speaker has restarted, and its peer should not wait for the End-of-RIB marker from the speaker before advertising routing information to the speaker. > > The draft does state that a lack of the forwarding state > bit for an AF or the lack of the capability for an AF will cause > stale routes to be flushed. No mention of the lack of the > restart state bit or the lack of the graceful restart > capability. Isn't obvious that "lack of the graceful restart capbility" implies "lack of the capability for an AF" (actually for all AFs)? -- Enke Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA05204 for ; Wed, 14 Feb 2001 13:38:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 72C725DE46; Wed, 14 Feb 2001 13:37:30 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4E6B15DE33; Wed, 14 Feb 2001 13:37:30 -0500 (EST) Received: from tenornetworks.com (rtu.tenornetworks.com [63.77.213.2]) by segue.merit.edu (Postfix) with ESMTP id 10A1D5DE46 for ; Wed, 14 Feb 2001 13:37:27 -0500 (EST) Received: from tsillas (tsillas [192.168.0.133]) by tenornetworks.com (Switch-2.1.0/Switch-2.1.0) with SMTP id f1EIbPJ24602 for ; Wed, 14 Feb 2001 13:37:25 -0500 (EST) Reply-To: From: "James Tsillas" To: "IDR" Subject: graceful restart question Date: Wed, 14 Feb 2001 13:37:16 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-idr@merit.edu Precedence: bulk If the receiving speaker detected a TCP reset but the received capability turns out not to have the restart flag set (but did have the forwarding state bit set for some AFs) is it correct for the receiving speaker to flush stale routing information before the end-of-RIB is received? Is the restart flag only considered by restarting speakers to avoid deadlock or can it be used as an indication of whether a given peer has really restarted? The draft does state that a lack of the forwarding state bit for an AF or the lack of the capability for an AF will cause stale routes to be flushed. No mention of the lack of the restart state bit or the lack of the graceful restart capability. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA02898 for ; Wed, 14 Feb 2001 11:53:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id A196D5DE36; Wed, 14 Feb 2001 11:52:47 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8F79A5DE32; Wed, 14 Feb 2001 11:52:47 -0500 (EST) Received: from oak.ggn.net (oak.ggn.net [198.207.193.5]) by segue.merit.edu (Postfix) with SMTP id AB0775DE30 for ; Wed, 14 Feb 2001 11:52:45 -0500 (EST) Received: (qmail 17006 invoked by user marklist) by oak.ggn.net; 14 Feb 2001 16:52:44 -0000 Date: Wed, 14 Feb 2001 11:52:44 -0500 (EST) From: Mark Mentovai To: Bruno Rijsman Cc: Yakov Rekhter , IDR Subject: RE: handling unrecognized optional transitive attributes In-Reply-To: <49FF5C6DDBD8D311BBBD009027DE980C01AEF9CE@uniwest1.redstonecom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk Bruno Rijsman wrote: >I don't think that is safe in all cases. Consider for example aggregation >of the MP-REACH-NLRI attribute on a router which supports aggregation but >does not (yet) support the multi-protocol extensions: we don't want the >aggregate to copy the (unrecognized) MP-REACH-NLRI attribute of any >covered routes because that would implicitly withdraw the NLRI included in >the MP-REACH-NLRI of the covered route themselves (assuming the covered >routes are not suppressed due to the aggregate being summary-only). MP_REACH_NLRI is non-transitive. If you don't understand the attribute but copy it anyway, you're in violation of the spec, and have bigger problems than your behavior during aggregation. Mark Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA01807 for ; Wed, 14 Feb 2001 10:51:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0BFBF5DE6B; Wed, 14 Feb 2001 10:49:16 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EDCB65DE6A; Wed, 14 Feb 2001 10:49:15 -0500 (EST) Received: from oak.ggn.net (oak.ggn.net [198.207.193.5]) by segue.merit.edu (Postfix) with SMTP id 43F0D5DE46 for ; Wed, 14 Feb 2001 10:49:14 -0500 (EST) Received: (qmail 15476 invoked by user marklist) by oak.ggn.net; 14 Feb 2001 15:49:09 -0000 Date: Wed, 14 Feb 2001 10:49:09 -0500 (EST) From: Mark Mentovai To: Yakov Rekhter Cc: IDR Subject: Re: handling unrecognized optional transitive attributes In-Reply-To: <200102141356.FAA80509@garnet.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk Yakov Rekhter wrote: >The current BGP spec doesn't say anything wrt how a BGP speaker >that aggregates several routes should handle optional transitive >attributes of these routes if the speaker doesn't recognize the >attributes. We should probably need to specify how to handle this. >One option would be to require the speaker to drop these attributes. >Any other (reasonable) options ? How about this: if all of the routes being aggregated contain identical instances of the unknown optional transitive attribute in question, the BGP speaker should include the attribute in the aggregated route, with the partial bit set, but may instead drop the attribute. If the routes being aggregated don't all contain identical instances of the unknown attribute, the attribute must not be included in the aggregated route. Does that sound sane? Sound like it'll break anything? Mark Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA00598 for ; Wed, 14 Feb 2001 09:51:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3A3315DDC9; Wed, 14 Feb 2001 09:50:52 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 276245DDDD; Wed, 14 Feb 2001 09:50:52 -0500 (EST) Received: from merlin.prod.itd.earthlink.net (merlin.prod.itd.earthlink.net [207.217.120.156]) by segue.merit.edu (Postfix) with ESMTP id ABD5B5DDC9 for ; Wed, 14 Feb 2001 09:50:50 -0500 (EST) Received: from optic3.ipoptical.com (dialup-166.90.26.179.Washington1.Level3.net [166.90.26.179]) by merlin.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with ESMTP id GAA05170; Wed, 14 Feb 2001 06:50:47 -0800 (PST) Received: by optic3.ipoptical.com with Internet Mail Service (5.5.2653.19) id <1PYLM9D3>; Wed, 14 Feb 2001 09:48:18 -0500 Message-ID: From: Ben Abarbanel To: "'Yakov Rekhter'" , "'idr@merit.edu'" Subject: RE: handling unrecognized optional transitive attributes Date: Wed, 14 Feb 2001 09:48:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idr@merit.edu Precedence: bulk Yakov: I thought optional transitive means the attribute is passed through without being dropped? Ben -----Original Message----- From: owner-idr@merit.edu [mailto:owner-idr@merit.edu]On Behalf Of Yakov Rekhter Sent: Wednesday, February 14, 2001 8:57 AM To: idr@merit.edu Subject: handling unrecognized optional transitive attributes Folks, The current BGP spec doesn't say anything wrt how a BGP speaker that aggregates several routes should handle optional transitive attributes of these routes if the speaker doesn't recognize the attributes. We should probably need to specify how to handle this. One option would be to require the speaker to drop these attributes. Any other (reasonable) options ? Yakov. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA29609 for ; Wed, 14 Feb 2001 09:01:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4EF075DE53; Wed, 14 Feb 2001 08:57:35 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E37525DE2D; Wed, 14 Feb 2001 08:56:45 -0500 (EST) Received: from red.juniper.net (red.juniper.net [207.17.136.137]) by segue.merit.edu (Postfix) with ESMTP id 5AB9D5DE27 for ; Wed, 14 Feb 2001 08:56:41 -0500 (EST) Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id FAA23767 for ; Wed, 14 Feb 2001 05:56:40 -0800 (PST) Received: from garnet.juniper.net (localhost [127.0.0.1]) by garnet.juniper.net (8.9.3/8.9.3) with ESMTP id FAA80509 for ; Wed, 14 Feb 2001 05:56:40 -0800 (PST) (envelope-from yakov@garnet.juniper.net) Message-Id: <200102141356.FAA80509@garnet.juniper.net> To: idr@merit.edu Subject: handling unrecognized optional transitive attributes MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <80506.982159000.1@garnet.juniper.net> Date: Wed, 14 Feb 2001 05:56:40 -0800 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Folks, The current BGP spec doesn't say anything wrt how a BGP speaker that aggregates several routes should handle optional transitive attributes of these routes if the speaker doesn't recognize the attributes. We should probably need to specify how to handle this. One option would be to require the speaker to drop these attributes. Any other (reasonable) options ? Yakov. Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA10156 for ; Thu, 8 Feb 2001 11:35:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 61E735DE52; Thu, 8 Feb 2001 11:34:56 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 49B6C5DE51; Thu, 8 Feb 2001 11:34:56 -0500 (EST) Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by segue.merit.edu (Postfix) with ESMTP id 6595D5DE46 for ; Thu, 8 Feb 2001 11:34:54 -0500 (EST) Received: from C353136A (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id IAA03852; Thu, 8 Feb 2001 08:34:53 -0800 (PST) Message-ID: <008c01c091ec$67c75540$ed1c1418@snvl1.sfba.home.com> Reply-To: "Srinivasa Chaganti" From: "Srinivasa Chaganti" To: , "Yakov Rekhter" References: <200101311447.GAA38667@garnet.juniper.net> Subject: Re: 4 bytes ASs Date: Thu, 8 Feb 2001 08:30:10 -0800 Organization: Pluris MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-idr@merit.edu Precedence: bulk Hi, I have some suggestions on avoiding conversions between 2 bytes AS numbers and 4 bytes AS numbers until 4 bytes AS numbers are really in use. We can avoid this conversion process by defining another optional attribute (ASP_TYPE) which tells whether the numbers in as-path are in 2 bytes format or in 4 bytes format. When NEW_BGP_SPEAKER is sending a path to another NEW_BGP_SPEAKER if the path is already in 2 bytes format sending side just needs to add ASP_TYPE attribute to tell the peer that the AS numbers in the path are in 2 bytes format. On the receiving side NEW_BGP_SPEAKER interprets the AS numbers based on whether ASP_TYPE attribute is present or not. This also helps in avoiding conversion process on NEW_BGP_SPEAKERs when sending 2 bytes value AS numbers from 4 bytes before sending to OLD_BGP_SPEAKERs. This procedure saves memory, CPU, and bandwidth until that time when 4 bytes AS numbers are really in use. Once every path in the network contain at least one 4 bytes AS number in them, that time we can get rid of using ASP_TYPE attribute. any comments?? S. Chaganti ----- Original Message ----- From: "Yakov Rekhter" To: Sent: Wednesday, January 31, 2001 6:47 AM Subject: 4 bytes ASs > Folks, > > As we agreed at the last WG meeting, here is the document. > > Yakov. > ------- Forwarded Message > > Date: Wed, 31 Jan 2001 07:15:13 -0500 > From: Internet-Drafts@ietf.org > To: IETF-Announce: ; > cc: idr@merit.edu > Subject: I-D ACTION:draft-ietf-idr-as4bytes-00.txt > > - --NextPart > > 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 : BGP support for four-octet AS number space > Author(s) : Q. Vohra, E. Chen > Filename : draft-ietf-idr-as4bytes-00.txt > Pages : 7 > Date : 30-Jan-01 > > Currently the Autonomous System number is encoded in BGP as a two- > octets field. This document describes extensions to BGP to carry the > Autonomous System number as a four-octets field. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-00.txt > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-idr-as4bytes-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-idr-as4bytes-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > - --NextPart > Content-Type: Multipart/Alternative; Boundary="OtherAccess" > > - --OtherAccess > Content-Type: Message/External-body; > access-type="mail-server"; > server="mailserv@ietf.org" > > Content-Type: text/plain > Content-ID: <20010130111631.I-D@ietf.org> > > ENCODING mime > FILE /internet-drafts/draft-ietf-idr-as4bytes-00.txt > > - --OtherAccess > Content-Type: Message/External-body; > name="draft-ietf-idr-as4bytes-00.txt"; > site="ftp.ietf.org"; > access-type="anon-ftp"; > directory="internet-drafts" > > Content-Type: text/plain > Content-ID: <20010130111631.I-D@ietf.org> > > - --OtherAccess-- > > - --NextPart-- > > > > ------- End of Forwarded Message > Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA09527 for ; Thu, 8 Feb 2001 11:06:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 33C095DE48; Thu, 8 Feb 2001 11:05:35 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1D4A25DE4E; Thu, 8 Feb 2001 11:05:35 -0500 (EST) Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by segue.merit.edu (Postfix) with ESMTP id 3C5AD5DE48 for ; Thu, 8 Feb 2001 11:05:33 -0500 (EST) Received: from C353136A (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id IAA01895 for ; Thu, 8 Feb 2001 08:05:32 -0800 (PST) Message-ID: <007901c091e8$4dd4b640$ed1c1418@snvl1.sfba.home.com> Reply-To: "Srinivasa Chaganti" From: "Srinivasa Chaganti" To: References: Subject: Re: Query in Route Refresh Capability Date: Thu, 8 Feb 2001 08:00:48 -0800 Organization: Pluris MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-idr@merit.edu Precedence: bulk With route refresh capability, you still need to keep all the feasible routes locally after applying inbound policies (routes which are not filtered out by inbound policies) for each neighbor, though some of them are non best routes. When BGP speaker receives withdrawn message for a route it finds next best route among feasible routes received from other peers. With route refresh capability, you need not maintain received routes (i.e., before applying inbound policies) in the local system as you can get them from neighbor by route-refresh request as and when needed. S. Chaganti ----- Original Message ----- From: "Venu V." To: Sent: Wednesday, February 07, 2001 11:42 PM Subject: Query in Route Refresh Capability > > The Route Refresh Capability RFC 2918, suggests a way for sending > ROUTE-REFRESH messages so that the peer can send its Adj_RIB_Out table. This > helps the BGP speaker to avoid keeping Adj_RIB_In tables. > > But how are Withdrawn messages handled in this context, in the absence of > Adj_RIB_In? > > When a BGP speaker receives Withdrawn message, it needs to find the next > feasible/replacement route to that prefix. If it does not maintain the > Adj_RIBs_In, from where does it gets the information. > > > Thanks in Advance, > Venu > Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id CAA29980 for ; Thu, 8 Feb 2001 02:43:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3B40A5DE2A; Thu, 8 Feb 2001 02:42:54 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 24F5F5DE38; Thu, 8 Feb 2001 02:42:54 -0500 (EST) Received: from xover.hjinc.com (unknown [38.160.241.130]) by segue.merit.edu (Postfix) with ESMTP id B404A5DE2A for ; Thu, 8 Feb 2001 02:42:52 -0500 (EST) Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21) id <1NR0V9TA>; Thu, 8 Feb 2001 02:39:45 -0500 Message-ID: From: "Venu V." To: idr@merit.edu Subject: Query in Route Refresh Capability Date: Thu, 8 Feb 2001 02:42:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idr@merit.edu Precedence: bulk The Route Refresh Capability RFC 2918, suggests a way for sending ROUTE-REFRESH messages so that the peer can send its Adj_RIB_Out table. This helps the BGP speaker to avoid keeping Adj_RIB_In tables. But how are Withdrawn messages handled in this context, in the absence of Adj_RIB_In? When a BGP speaker receives Withdrawn message, it needs to find the next feasible/replacement route to that prefix. If it does not maintain the Adj_RIBs_In, from where does it gets the information. Thanks in Advance, Venu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA00966 for ; Wed, 7 Feb 2001 14:21:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id ABB865DE33; Wed, 7 Feb 2001 14:21:02 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 97D875DDF7; Wed, 7 Feb 2001 14:21:02 -0500 (EST) Received: from postal.redback.com (prattle.redback.com [155.53.12.9]) by segue.merit.edu (Postfix) with ESMTP id 396155DE19 for ; Wed, 7 Feb 2001 14:21:01 -0500 (EST) Received: from popserv3.redback.com (popserv3.redback.com [155.53.12.64]) by postal.redback.com (Postfix) with ESMTP id 45E77B76783; Wed, 7 Feb 2001 11:20:55 -0800 (PST) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv3.redback.com (Postfix) with ESMTP id 1C7DA7FF84; Wed, 7 Feb 2001 11:20:55 -0800 (PST) To: jtsillas@tenornetworks.com Cc: "IDR" , enke@redback.com Subject: Re: Graceful Restart: end-of-RIB marker per address-family? In-Reply-To: Message from "James Tsillas" of "Wed, 07 Feb 2001 13:48:37 EST." Date: Wed, 07 Feb 2001 11:20:55 -0800 From: Enke Chen Message-Id: <20010207192055.1C7DA7FF84@popserv3.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Hi, Jim: See the following text from Section 6 (Operation): ----- The End-of-RIB marker should be sent by a BGP speaker to its peer once it completes the initial routing update (including the case when there is no update to send) for an address family after the BGP session is established. ----- The End-of-RIB marker is defined and used on a per address family basis. -- Enke > From: "James Tsillas" > To: "IDR" > Subject: Graceful Restart: end-of-RIB marker per address-family? > Date: Wed, 7 Feb 2001 13:48:37 -0500 > Message-ID: > MIME-Version: 1.0 > > The draft (Graceful Restart Mechanism for BGP) doesn't > explicitly state if it is required that and end-of-RIB > (EOR) marker be sent (and received) per address-family > (AF), although it does indicate how the EOR is defined > for IPv4 and for MP-BGP. > > Is one to assume that EOR is sent per AF? > > Can a restarting speaker restart the AFs indepently, if > each AF would have its own EOR? > > thanks, > -Jim. > Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA29534 for ; Wed, 7 Feb 2001 13:50:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3561B5DDB3; Wed, 7 Feb 2001 13:49:17 -0500 (EST) Delivered-To: idr-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1AAB65DE00; Wed, 7 Feb 2001 13:49:17 -0500 (EST) Received: from tenornetworks.com (rtu.tenornetworks.com [63.77.213.2]) by segue.merit.edu (Postfix) with ESMTP id 671F95DDB3 for ; Wed, 7 Feb 2001 13:49:15 -0500 (EST) Received: from tsillas (tsillas [192.168.0.133]) by tenornetworks.com (Switch-2.1.0/Switch-2.1.0) with SMTP id f17InDJ13086 for ; Wed, 7 Feb 2001 13:49:14 -0500 (EST) Reply-To: From: "James Tsillas" To: "IDR" Subject: Graceful Restart: end-of-RIB marker per address-family? Date: Wed, 7 Feb 2001 13:48:37 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-idr@merit.edu Precedence: bulk The draft (Graceful Restart Mechanism for BGP) doesn't explicitly state if it is required that and end-of-RIB (EOR) marker be sent (and received) per address-family (AF), although it does indicate how the EOR is defined for IPv4 and for MP-BGP. Is one to assume that EOR is sent per AF? Can a restarting speaker restart the AFs indepently, if each AF would have its own EOR? thanks, -Jim.