Enke Chen wrote:
Hi, Mark:
I was no vacation and just became aware of this thread.
Lucky you!
> I have some clarifications here:
(1) The relevant implementation is "Encapsulating MPLS in IP or Generic
Routing Encapsulation (GRE)" for L3VPN (draft-ietf-mpls-in-ip-or-gre-xx.txt)
This draft describes encapsulation and decapsulation of MPLS over IP, MPLS over GRE (with and without optional GRE fields), and (in more recent versions) touches on all of these encapsulation modes in the presence of IPsec. There is no detail on dynamic establishment of GRE tunnels here.
(2) Redback's implementation does not require manual configuration of
and GRE tunnels in this case. We have tested the interoprability
with another implementation that does require manual configuration.
I don't doubt that this can be made to work. However, there are out-of-band assumptions here beyond simple support for "MPLS over GRE" which was my initial point. e.g., in order to interoperate, a "soft" GRE tunnel node must make assumptions that every node it is sending a GRE encapsulated MPLS packet to is either (1) manually configured to accept MPLS over GRE from that endpoint, or (2) is a PE which is participating in the same "soft" GRE system, learning endpoints from BGP updates or some other method. This is, of course, made easier when nodes are simply configured to allow MPLS over GRE/IP from any source IP address, but this also substantially increases the spoofing concerns for MPLS over GRE/IP at that node.
IMHO, if an implementation is going to be made to dynamically learn the destination address for an MPLS over IP enabled endpoint from BGP, including an attribute to explicitly identify the ability to receive said MPLS over IP packets goes a long way to overcome blackhole situations where one could end up sending tunneled packets to a PE which isn't able to receive and process them correctly.
Thanks,
- Mark