Ok.... Thanks 4 that quick reaction...!!

So what I understand is to forward the multicast traffic thru an IPSec Tunnel we need to encapsulate in GRE... Kind of a work around!! right... Is this even required in the follwing senatio as well

R1<----------------------->R2

R1 and R2 Runnnig EIGRP and is connected thru IPSEC tunnel is betwen R1 and R2

Absolutely correct. IPSec tunnel does not support encrypt/decrypt of multicast traffic, therefore if you need to pass routing protocols through IPSec tunnel, it needs to be encapsulated in GRE first prior to being encrypted in ESP.

If you have R1 and R2 connected directly, they can participate in dynamic routing protocols in clear text. However, if you need the routing protocols to be encrypted, you still need to encapsulate it in GRE prior to being encrypted.

In which all other scenarios we may require GRE Tunnels??

Most IPSec tunnels are routed through the Internet, and you can't run IGP on the Internet, hence, you would configure GRE over IPSec tunnels to pass the routing updates.

If your internal networks are through MPLS cloud, most MPLS provider does not allow you to run your IGP, hence it needs to be encapsulated through GRE.

But even though they allow, since IPSEC cannot handle multicast.. we should use GRE!!! Right...

You are absolutely right. All multicast traffic needs to be encapsulated in GRE prior to being encrypted in IPSec as IPSec does not support multicast traffic natively.

I do feel that GRE is a real work around, I do remember a scenario of OSPF, which have a rule that all areas should be connected directly to area 0. and when the scenario violates this rule, we can use a virtual link, I think in that case also we use GRE ??

Yes, GRE is the only solution if you would like to use IPSec to pass through the routing protocols.