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

Rahul Aggarwal <rahul@JUNIPER.NET> Mon, 10 November 2003 16:59 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 LAA00121 for <ospf-archive@LISTS.IETF.ORG>; Mon, 10 Nov 2003 11:59:45 -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 <22.00C3F2FA@cherry.ease.lsoft.com>; Mon, 10 Nov 2003 11:59:56 -0500
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60042317 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 10 Nov 2003 11:59:53 -0500
Received: from 207.17.136.150 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Nov 2003 11:49:41 -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 hAAGnfi17947 for <OSPF@PEACH.EASE.LSOFT.COM>; Mon, 10 Nov 2003 08:49: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 hAAGneM85470 for <OSPF@PEACH.EASE.LSOFT.COM>; Mon, 10 Nov 2003 08:49: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>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Message-ID: <20031110084404.A84355@sapphire.juniper.net>
Date: Mon, 10 Nov 2003 08:49:40 -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: <3F9EB8F2.10002@cisco.com>
Precedence: list

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.

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.
>