[Idr] Re: BGP issues
Robert Raszuk <raszuk@juniper.net> Fri, 11 January 2008 17:01 UTC
Return-path: <idr-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDNG1-00087m-Ht; Fri, 11 Jan 2008 12:01:25 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDNG0-00087h-1d for idr@ietf.org; Fri, 11 Jan 2008 12:01:24 -0500
Received: from exprod7og104.obsmtp.com ([64.18.2.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JDNFz-0000nt-96 for idr@ietf.org; Fri, 11 Jan 2008 12:01:24 -0500
Received: from source ([66.129.224.36]) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP; Fri, 11 Jan 2008 09:01:18 PST
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Jan 2008 08:57:55 -0800
Received: from [172.26.250.99] ([172.26.250.99]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m0BGvs985493; Fri, 11 Jan 2008 08:57:55 -0800 (PST) (envelope-from raszuk@juniper.net)
Message-ID: <4787A011.3070309@juniper.net>
Date: Fri, 11 Jan 2008 08:57:53 -0800
From: Robert Raszuk <raszuk@juniper.net>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Iljitsch van Beijnum <iljitsch@muada.com>
References: <200801061814.m06IE8920382@magenta.juniper.net> <22AB40E0-1660-4B9D-BA74-B1CB98EB0882@cisco.com> <47813E05.2050602@juniper.net> <A627A8DF-42D2-4701-A6D5-1C8102537A41@cisco.com> <4781FFEA.8050800@juniper.net> <4782170D.2040200@cisco.com> <478252F3.4000809@juniper.net> <4782D04B.50703@gmail.com> <47832402.9090001@cisco.com> <47833D03.7050005@juniper.net> <4783E670.5080003@gmail.com> <4783EA14.2030900@juniper.net> <4783F0B8.3070401@gmail.com> <4783F4A8.2000506@juniper.net> <792E56AD-25FB-4942-B649-FAF12DBEFD77@muada.com> <4784C5EF.1070806@juniper.net> <7006D2FB-DE3D-4DB2-80FF-B16D21C2347B@muada.com>
In-Reply-To: <7006D2FB-DE3D-4DB2-80FF-B16D21C2347B@muada.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 11 Jan 2008 16:57:55.0801 (UTC) FILETIME=[1C9BE490:01C85473]
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027
Cc: idr <idr@ietf.org>
Subject: [Idr] Re: BGP issues
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: raszuk@juniper.net
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
Errors-To: idr-bounces@ietf.org
Hi Iljitsch, >>> In addition to the fact that it's possible to configure iBGP such >>> that you can have routing loops? > >> Could you provide an example ? > > R1e - R2i - R3i - R4e > > If R1 and R4 both prefer their eBGP path towards a certain destination > and then R2 prefers the path over R4 while R3 prefers the path over R1, > packets will loop between R2 and R3. Note that this configuration only > happens when applying policy to iBGP sessios or in unfortunate route > reflector placement. Altering best path selection on IBGP routers is a bad idea when you have hop by hop switching. >> BGP can converge today in subseconds. > > Sure, but it can also take many minutes, especially with a > min-route-advertisement timer in effect in many places and if the update > is a withdrawl. Now I've argued that this shouldn't be too problematic > because if you're revoking your advertisement that means you're > unreachable anyway, but not everyone agrees with that. (Not good if you > are revoking a more specific and you want the aggregate to attract the > traffic.) > > One reason that BGP is getting chattier is because updates tend to be > multiplied if there are several interconnects between two ASes. Just to clarify here .. what I call convergence is in fact reachability restoration. And that is in vast majority of cases just the thing within your AS or at most to your peering AS. As long as reachability is restored (even if temporarily in an suboptimal fashion) does not impact user's traffic. Then BGP can take as long as it likes to "converge" to an optimal path as long as reachability is in place. That IMHO should be the focus. >> Not true. There is proposal for BGP aggregate withdraw. > > I'm talking about what's out there, not about what's proposed. Very > little of what is proposed makes it to wide deployment. If you say that very little on what is proposed or what vendors ship makes it to the actual wide deployment what could we say about something which is not even proposed yet ? Should we sit and do nothing for years to come ??? >> Accommodating policies is not a BGP protocol requirement but it comes >> from operators using this protocol to fit their operational needs. > > Sure, but in my opinion, BGP takes it a bit too far, it's too easy to > shoot yourself in the foot. Or, in other words: a routing protocol that > allows loops is doing something wrong. See the problem is that loops can form with bad policies. And it would not be that hard to detect them algorithmically. The problem is that no operators wants to share his polices to others. So while you could quite easy come out with the intra-domain policy verifier .. doing the same inter-domain is a non technical challenge. I don't think BGP or any other protocol would do any magic if there is no data at hand to work on. >> What other metrics would you recommend to add to BGP and how that >> would that reduce deaggregation ? > > I would like to see a value that is increased by every AS (twice, for > good measure: once on reception, once on transmission), but not by one, > but by a value (say) between 1 and 127, with a default in the middle > (11). So where you'd see an AS path length 3 today, you'd see a metric > value 66 if nobody in the path changed the default. But if someone wants > to make this path just a little better or a little worse, they can make > it 65 or 67. This allows finer grained control that the AS path so it > reduces the need for deaggregation for TE purposes. Hmmmm that's an idea ... Perhaps you should write a brief draft on it ? >> IMHO this is a feature not a bug. In fact for convergence reasons this >> is a very useful feature to have fast IGP. > > It also adds tons of complexity, especially if you don't want to have a > full iBGP mesh. I'm not saying you shouldn't have an IGP, I'm saying you > shouldn't _have_ to have an IGP. IMHO recursive protocol should recurse via something. And for intra-domain reachability restoration bgp is not the best choice. I saw in the past some attempts to use iBGP as an IGP but it is IMHO a very bad idea limited to very few specific topologies. The issue is that intra and inter domain requirements for routing protocol are very different and diverse. It is a challenge to come up with a huge protocol to do all .. as such would not do anything very good. On that grounds I do believe that we should have precise tools for different jobs. For the same reason I have a big workshop in my garage not to have bend wires, cut wood or unscrew car bolts all with one set of pliers. >> When the ability to send more then best path is added true .. paths >> would have to be explicitly revoked. Any other proposal in RRG does >> the very same. > > It would be better if implementations wouldn't have to keep track of > what they sent where. However, this is probably relatively easy to fix > ("start now" .... "forget all the prefixes that I haven't refreshed > since "start now"") but the fix will probably be hard to deploy. Then you would loose the huge benefit of BGP to be an incremental protocol ! Cheers, R. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr
- [Idr] Re: BGP issues Robert Raszuk
- [Idr] Re: BGP issues Iljitsch van Beijnum
- [Idr] Re: BGP issues Robert Raszuk
- RE: [Idr] Re: BGP issues Rajiv Asati (rajiva)
- Re: [Idr] Re: BGP issues John G. Scudder
- Re: [Idr] Re: BGP issues Paul Jakma