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

[Gargi Nalawade <[e-mail]>]

Hi Rahul,

Thanks for your comments.

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

Not always. There are tunnels which are purely intra-domain as well.

> 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

The above BGP solutions can be used only in BGP networks. There are
BGP-free networks that require tunneling Capabilities as well and we
are receiving requests from those customers to provide a complementary
solution that does not rely on BGP being present.

Also - for the 2 specific drafts mentioned above, BGP uses the routes
learnt through an IGP to resolve the nexthop to BGP prefixes. But in
the presence of tunnels, this reachability is not sufficient and the
reachability via the tunnels has to be propagated as well. The BGP
solution has been created purely for the inter-Provider case where there
is no inter-AS mechanism other than BGP to propagate that. But within
a given network, when the tunnels are required only within an AS or domain,
the IGP provides the reachability to the Tunnel end-point and hence is the
right place to carry the tunnel reachability information as well.

> Hence imho OSPF WG should not take on this work.

Hence I believe that the IGP is the right place to carry the above and
IMHO, the OSPF WG should take on this work.

Thanks,
Gargi

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