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

[Gargi Nalawade <[e-mail]>]

Hi Rahul,

Inline...

Rahul Aggarwal wrote:
>
> 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

By that argument why have anything that is in both BGP & IGP? Why have
redistribution between protocols at all? :)

The inter-AS - more expensive solution would be used when inter-AS tunnels
are needed, whereas the intra-AS solution can be used in case of intra-AS
tunnels and also if a Provider wants to propagate tunnel information within
its domain using an IGP and redistribute only the inter-AS information on
the border PEs. This completes the solution. These are not competing solutions.
One complements and completes the other and caters to those customers who do
not want to run BGP to signal these tunnel end-points and want to treat them
(correctly) as part of IGP reachability.

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

Not necessarily. Depends on the application. You are narrowing down the scope
to a particular application - which is why you think PE. I agree that common
scenarios would be PE-to-PE. But that does not mean that there won't be scenarios
that have P routers as endpoints. TE-tunnels is one example.

Also note that this draft is a framework for tunnel endpoint signalling and
how and where it is deployed/used and whether the tunnel endpoints are PEs
or Ps depends on the specific application a Provider or an Enterprise has
in mind.

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

You are only thinking Provider VPNs. In that case yes - the PEs will run
BGP. But like I said this is not limited to Provider VPNs and hence the
tunnel endpoints could be just vanilla IGP routers.

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

Because the reachability would be through the tunnel. Unless the tunnel
comes up - traffic cannot begin to flow through it and hence the destination
is still unreachable as long as the Tunnel endpoint encapsulation is not
received. That really belongs in the IGP which is what provides the reachability
to the endpoint.

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

Well, thats upto you, if you want to define that. ;-) I'm not the one saying that.

Thanks,
Gargi

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