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

[Sandy Eng <[e-mail]>]

Rahul,

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

As we are announcing specific router capabilities, it therefore infers
that only certain routers in the network are capable of some specific
capabilities. If all routers in a network have the same capability,
there is then no need for specific announcement.

Thanks,
Sandy



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