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

[Sandy Eng <[e-mail]>]

Rahul,

Rahul Aggarwal wrote:
> Hi Sandy,
>
> On Mon, 10 Nov 2003, Sandy Eng wrote:
>
>
>>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.
>>
>
>
> The tunnel encapsulations are needed by the PE routers and are advertised
> by the PE routers. Different PE routers can advertise different tunnel
> capabailities. However P routers do not require this information.

When a capability is announced, one does not expect all routers in a
network to react to such capability. One example is
draft-vasseur-mpls-ospf-te-cap-00.

Do we then require that the RI LSA carries capability information only
if all routers in a network need it? If so, I don't see this requirement
mandated in draft-lindem-ospf-cap-01.

I agree we should not simply stuff any type of information in OSPF. But
this should be looked at from application to application. Most of the
times, a router announcing as a tunnel endpoint does not change its
status. Tunnel application can be mostly viewed as a single shot.

Furthermore, there are enterprise networks that are only running IGP
(OSPF in this case), which wish to establish tunnels to divert special
class of traffic. In such cases, OSPF needs to provision this dynamic
discovery.

In a VPN enviroment, OSPF converges in sub-seconds while BGP in minutes,
OSPF can deliver the tunnel endpoint information much faster than BGP,
enabling faster traffic reachibility.

Thanks,
Sandy





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