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

[Robert Raszuk <[e-mail]>]

Hi Yakov,

Practical cases I have in mind is the pragmatic approach to reuse
existing and deployed machinery for flooding information versus
designing new one from scratch.

That applies to BGP, IGPs, LDP, PIM etc ....

I essentially see nothing wrong with providing some one the ability to
use OSPF for distributing session IDs and cookies in this example if
they wish to do so for some reason.

As example for provider who wish to use 2547bis over L2TPv3 for whatever
reason and happens to have quite a few confederations with a common IGP
it seems simpler to use IGP then a sequence of IBGP/EBGP cycles to get
the information distributed.

So to make myself clear I would like to see if there is an agreement in
general for "protocol reuse". I also think that at some time it may turn
better to just define a user configurable container (ala community
field) in IGPs where users could put their data and flood without the
need to go via new code / new draft each time a need to flood something
arises.

Cheers,
R.


 > Yakov Rekhter wrote:
 >
>>Sandy,
>>
>>
>>>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.
>>
>>I can't agree with this statement.
>>
>>BGP convergence intra domain - note within _single_ domain can be in
>>fact almost as fast for tunnel AFI/SAFI then for OSPF. In fact with
>>default timers in OSPF and with prioritizing tunnel AFI/SAFI first (as
>>it should be the case) I could argue that even today with most BGP
>>implementations it will converge faster then OSPF when the number of
>>your P routers is decent.
>>
>>I think we could debate more - and yes this draft itself solves some
>>practical cases with not too big overhead for IGPs - but let's at least
>
>
> Could you please enumerate these cases.
>
> Yakov.
>