North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: iMPLS benefit
Please see inline. Yakov Rekhter wrote:
Are you referring to draft-raggarwa-ppvpn-tunnel-encap-sig-03.txt? (Just guessing as the principal author used to work for Redback). Thanks for the update, I was in fact not aware that companies other than Redback had implemented it. You didn't name those companies, but I will happily stand corrected here.Mark,The only multi-vendor interoperable mode of GRE that I am aware of requires manual provisioning of point-to-point GRE tunnels between MPLS networks and to each and every IP-only reachable PE.i heard there is a way to run MPLS for layer3 VPN(2547)
In any case, the point I was trying to make was that there is more than one way to do "MPLS over GRE" and that they are not all necessarily interoperable as you seemed to imply in your message. You have helped to make that quite clear.
Both draft-nalawade-kapoor-tunnel-safi-01.txt and draft-raggarwa-ppvpn-tunnel-encap-sig-03.txt use BGP to advertise capabilities for carrying MPLS-labeled packets over various encapsulation types. Proof of one is essentially proof for the other, though the existence of both definitions highlights an unfortunate interoperability concern (particularly so for GRE, since each identify slightly different ways to advertise MPLS over GRE).The BGP extension defined in the draft below allows "iMPLS" for 2547 VPN support without requiring any manually provisioned tunnels (and works for "mGRE" or L2TPv3).
If you are not advertising capabilities at all, then you either have to maintain a list of which PEs can and will perform 2547 over GRE (and we are back to manual provisioning of tunnels), or you have to assume that ALL will in precisely the same way (eliminating all native MPLS processing for PEs that are reachable via MPLS directly).
And the same paragraph goes on to say:Note that "mGRE" (multipoint GRE) is *not* the same as the point-to-point GRE
"The maintenance of these filter lists can be
management-intensive, and the their use at all border routers can
affect the performance seen by all traffic entering the SP's network."
So, 2547 over GRE without IPsec relies upon a valid source/dest IP check for each packet at all boundary points in the network. Rather than rely only on this, the 2547 over L2TPv3 encapsulation defines its own (randomly selected and advertised along with the tunnel capabilities for that PE) 64-bit value to be validated before processing a packet at the router which is actually performing the 2547 VPN service.
Both of these methods are filtering on cleartext header information in order to avoid the complexity and overhead of IPsec while inhibiting "script-kiddie-like" IP spoofing attacks attempting to infiltrate a VPN, but 2547 over L2TPv3 gets around the concerns with 2547 over GRE identified above as there are no filter lists to be manually maintained, and the filtering is performed only on the routers actually participating in 2547 over L2TPv3 service.