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

[Sandy Eng <[e-mail]>]

Ravi,

Sastry, Ravi wrote:
>  Any MTU issues especially when there are large
>  number of tunnels? Just wondering..

OSPF relies on IP for fragmentation, there's no difference with this LSA.

Thanks,
Sandy



>
>
>  ravi/
>
>
>
>>-----Original Message-----
>>From: Sandy Eng [mailto:[e-mail]]
>>Sent: Monday, November 10, 2003 3:58 PM
>>To: [e-mail]
>>Subject: Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt
>>
>>
>>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.
>>>>
>>>