Yakov Rekhter wrote:
No, I was *not* referring to draft-raggarwa-ppvpn-tunnel-encap-sig-03.txt. Redback's implementation that does not require manual provisioning of point-to-point GRE tunnels between MPLS networks and to each and every IP-only reachable PE is *purely* an implementation matter, and does *not* require any new communities and/or attributes.
OK, you made me go out to www.redback.com and read about their implementation. A quote: "This means that the ingress router can learn these next-hop addresses through MP-BGP, and then dynamically append the GRE encapsulation and outer IP header to a VPN packet destined for an egress router. In essence, these GRE tunnels can be considered as “soft” or dynamic because they do not need to be configured. " Whether it is implicit from the next-hop address in BGP, or explicit in the next-hop update via draft-nalawade-kapoor-tunnel-safi-01.txt or draft-raggarwa-ppvpn-tunnel-encap-sig-03.txt, we are still talking about MP-BGP as the vehicle for advertising how to reach a PE by GRE. We now have identified three variants for MPLS over GRE in this thread, (outside of manually configured "hard" GRE tunnels) -- back to my original point that "MPLS over GRE" can mean a lot of things. IMHO, a PE explicitly identifying that it can receive MPLS over GRE (or MPLS over foo) traffic is a bit safer and more deterministic than implicitly assuming it can from a learned next-hop address. I don't want to speak for another company, but perhaps Redback did too which is why they helped sponser draft-raggarwa-ppvpn-tunnel-encap-sig-03.txt in the first place. Go knock on Rahul's cube now that the two of you work at the same company and ask him ;-) - Mark