Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt

Yakov Rekhter <yakov@JUNIPER.NET> Wed, 12 November 2003 19:54 UTC

Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04163 for <ospf-archive@LISTS.IETF.ORG>; Wed, 12 Nov 2003 14:54:14 -0500 (EST)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00C431AC@cherry.ease.lsoft.com>; Wed, 12 Nov 2003 14:54:23 -0500
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60310948 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 12 Nov 2003 14:54:21 -0500
Received: from 207.17.136.150 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Nov 2003 14:54:21 -0400
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id hACJsKi63628 for <OSPF@PEACH.EASE.LSOFT.COM>; Wed, 12 Nov 2003 11:54:20 -0800 (PST) (envelope-from yakov@juniper.net)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <16065.1068666860.1@juniper.net>
Message-ID: <200311121954.hACJsKi63628@merlot.juniper.net>
Date: Wed, 12 Nov 2003 11:54:20 -0800
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Yakov Rekhter <yakov@JUNIPER.NET>
Subject: Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To: Your message of "Wed, 12 Nov 2003 15:16:48 +0100." <3FB240D0.70506@cisco.com>
Precedence: list

Robert,

> Gargi,
>
>  > core ipv4 routing. So let's not talk about BGP here.
>  >
>  > Reality is, in most generic implementations today, there is an order
>  > of magnitude difference between OSPF and BGP.
>
> Of course there is. And that's why we should not only talk about BGP
> here comparing both solutions as about some massive and huge monster but
> we do need to realize that Tunnel AFI/SAFI's properties and the number
> of few NLRIs it needs to carry in comparison with thousands of ipv4 or
> vpnv4 BGP carries is a very significant factor to keep in mind.

And moreover, we need to keep in mind that there is no need to carry
all of them over the same BGP session.

Yakov.

>
> Cheers,
> R.
>
>
>  > Gargi Nalawade wrote:
>  >
> > Robert,
> >
> > Robert Raszuk wrote:
> >
> >>Sandy,
> >>
> >>
> >>>In a VPN enviroment, OSPF converges in sub-seconds while BGP in minutes,
> >>>OSPF can deliver the tunnel endpoint information much faster than BGP,
> >>>enabling faster traffic reachibility.
> >>
> >>I can't agree with this statement.
> >>
> >>BGP convergence intra domain - note within _single_ domain can be in
> >>fact almost as fast for tunnel AFI/SAFI then for OSPF. In fact with
> >>default timers in OSPF and with prioritizing tunnel AFI/SAFI first (as
> >>it should be the case) I could argue that even today with most BGP
> >
> >
> > I dont quite agree with - 'prioritizing... as should be the case'. We
> > have debated this in the past and you know my stance. The stance of
> > multiple providers I have talked to, also seems to be the same. They
> > want a simple, scalable BGP which does not affect/compromise on their
> > core ipv4 routing. So let's not talk about BGP here.
> >
> > Reality is, in most generic implementations today, there is an order of
> > magnitude difference between OSPF and BGP.
> >
> >
> >>implementations it will converge faster then OSPF when the number of
> >>your P routers is decent.
> >
> >
> > Let's forget about the 'if's and 'when's for now. Plus convergence is
> > not the only major driving factor. There is a need for a non-BGP solution
> > expressed by the enterprise and provider space alike.
> >
> >
> >>I think we could debate more - and yes this draft itself solves some
> >>practical cases with not too big overhead for IGPs - but let's at least
> >
> >
> > Ok. So you agree that this draft solves practical cases. Hear Ya!
> >
> > -Gargi
> >