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

Rahul Aggarwal <rahul@JUNIPER.NET> Wed, 12 November 2003 05:16 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 AAA08383 for <ospf-archive@LISTS.IETF.ORG>; Wed, 12 Nov 2003 00:16:33 -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 <16.00C4215A@cherry.ease.lsoft.com>; Wed, 12 Nov 2003 0:16:43 -0500
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60234808 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 12 Nov 2003 00:16:42 -0500
Received: from 207.17.136.150 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Nov 2003 00:16:42 -0400
Received: from sapphire.juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id hAC5Gfi03377 for <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 11 Nov 2003 21:16:41 -0800 (PST) (envelope-from rahul@juniper.net)
Received: from localhost (rahul@localhost) by sapphire.juniper.net (8.11.6/8.11.3) with ESMTP id hAC5Gff16927 for <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 11 Nov 2003 21:16:41 -0800 (PST) (envelope-from rahul@juniper.net)
X-Authentication-Warning: sapphire.juniper.net: rahul owned process doing -bs
References: <3F9E9379.3070602@redback.com> <3F9EAD95.9050101@cisco.com> <3F9EB8F2.10002@cisco.com> <20031110084404.A84355@sapphire.juniper.net> <3FAFFBEC.7090409@cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Message-ID: <20031111211412.Y12111@sapphire.juniper.net>
Date: Tue, 11 Nov 2003 21:16:41 -0800
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Rahul Aggarwal <rahul@JUNIPER.NET>
Subject: Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To: <3FAFFBEC.7090409@cisco.com>
Precedence: list

Hi Sandy,

On Mon, 10 Nov 2003, Sandy Eng wrote:

> Rahul,
>
> Rahul Aggarwal wrote:
> > Following up on this thread, I have the following concerns with this
> > document:
> >
> > 1. Tunnels are used both intra and inter domains. Thus tunnel
> > capabilities have to be propagated across domains as well. Hence IGP is
> > imho not appropriate for this application.
> >
> > 2. Tunnel capabilities are not used by core routeres.
>
> As we are announcing specific router capabilities, it therefore infers
> that only certain routers in the network are capable of some specific
> capabilities. If all routers in a network have the same capability,
> there is then no need for specific announcement.
>

The tunnel encapsulations are needed by the PE routers and are advertised
by the PE routers. Different PE routers can advertise different tunnel
capabailities. However P routers do not require this information.

rahul

> Thanks,
> Sandy
>
>
>
> >
> > 3. There are existing documents that specify the use of BGP for this:
> > draft-raggarwa-ppvpn-tunnel-encap-sig-01.txt
> > draft-nalawade-kapoor-tunnel-safi-01.txt
> >
> > Hence imho OSPF WG should not take on this work.
> >
> > Thanks,
> > rahul
> >
> > On Tue, 28 Oct 2003, Robert Raszuk wrote:
> >
> >
> >>Acee,
> >>
> >>
> >>>     My biggest fear would be that if this draft is accepted it
> >>>     would only be the first of a torrent of auto-configuration
> >>>     drafts.
> >>
> >>Second one not first ;). Notice this one submitted a while back:
> >>draft-raszuk-ospf-bgp-peer-discovery-00.txt
> >>
> >> >     1. Should OSPF be used for tunnel auto-configuration?
> >>
> >>I think in general this requires a study on a case by case basis. Most
> >>important factors which should be taken into consideration are:
> >>
> >>*A* How frequently the information advertised changed - is it static
> >>configuration or dynamic in nature which triggers reflooding ?
> >>
> >>*B* Is the application which the uses delivered information limited to
> >>IGP domain or crosses domains ?
> >>
> >>*C* What is the amount of information to be flooded (keeping in mind
> >>that majority of P routers - those in the core - will never use it.
> >>
> >>*D* What are the alternatives available & _deployed_ today to deliver
> >>the same information to it's users
> >>
> >>*E* How often area wide flooding will be sufficient versus domain wide.
> >>
> >>Coming back to draft-eng-nalawade-ospf-tunnel-cap-00.txt I see the
> >>following:
> >>
> >>Reg A: Info is essentially static except the L2TPv3 cookie rollover
> >>intervals which if implementation permits could be changing periodically
> >>
> >>Reg B: I think that in any application of tunnels we can't limit the
> >>scope of use to one IGP domain. There can be a lot of customers who may
> >>never need to go over a domain (which this draft is targeting though).
> >>
> >>Reg C: Minimal (comparing to TE at least :):).
> >>
> >>Reg D: It is worth noting that there is a few drafts in IDR describing
> >>the ideas for the same information distribution
> >>
> >>Reg E: Looking at the most common OSPF topologies I would say that most
> >>tunnels will be build between edge PEs and those in a lot of cases are
> >>located in it's own POP areas. Not to say that there are no customers
> >>who keep most of their PEs on the edges of area 0.
> >>
> >>Rgs,
> >>R.
> >>
> >
>