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

[Robert Raszuk <[e-mail]>]

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.