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

[Rahul Aggarwal <[e-mail]>]

Hi Gargi,

Sorry for the delay. Please see inline:

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

The point is that one *has* to solve the inter-domain case. IGP cannot
do that unlike BGP based solutions which do that. Given that why a
different solution for the intra domain case ? Note that in a domain this
information is needed only by the PEs. It doesn't need to be flooded on
all the P routers.

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

The core maybe BGP free, but the PE routers will run BGP. Can you explain
the scenario when the PEs don't run BGP ?


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

For route resolution, the BGP next-hop needs to be reachable. The BGP
next-hop will be the tunnel endpoint address. This in turn will be an IGP
route. Why is this not sufficient ?

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

Then maybe IGPs should carry labelled VPN routes too in a domain ?

Thanks,
rahul


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