RE: WG LAST CALL on draft-ietf-ppvpn-vpn-vr-04.txt
Mark Duffy <[email protected]> Wed, 11 Jun 2003 18:32:32 -0400
| Newsgroups | gmane.ietf.ppvpn |
|---|---|
| Message-ID | <5.2.0.9.0.20030611171755.0295ad28@email> |
Hi Paul, thanks for your response. I agree with almost all your points :-) I have further questions on one point below. You are right that I did not correctly interpret the "backbone VR" concept as described. I think the additional explanation in your email would indeed be good to add to the document. I'll reread it with the new understanding. > > 8. VPNs across Domains > > [...] > > Another possible scenario is to use two virtual routers configured > > on each PE at the interconnection point. > > > > [md] I would clarify that as follows: > > Another possible scenario is to deploy PE devices at each side > > of the interconnection point, with a virtual router configured > > on each PE for each VPN that spans the interconnection point. > > >[pk] I think the VR-per-VPN may be overkill, depending on the granularity >of filtering needed. The idea is not to terminate the VPNs, but to >provide ingress/egress filtering for all the bidirectional tunneled VPN >traffic crossing the boundary. The VPN traffic should be opaque at the >boundary, so it would normally be filtered all-or-nothing (by VPN) based >on the visible packet identifiers (which could be mapped to a VPN by each >service provider, for instance using the VPN-ID). I'm not sure what other >policies would be applied by the service providers on the VPN traffic >transiting the boundary, but I don't think they would normally require a >VR per VPN on the boundary. [md2] Ah, ok, I see that the text was not meant to suggest a VR per VPN at the peering point (I agree that would be unnecessary in most cases). But I don't understand yet what it does mean. If the objective is to filter packets of certain VPNs (or more precisely, filter packets on certain virtual links) then why are any VRs needed? Is this to terminate the VPN represented by some "backbone VRs" to get visibility into the nested VPNs? Is "two virtual routers configured on each PE" really meant to mean two on the first PE and two on the second, or two altogether (one on each)? It seems in any event that one could only filter packets on those tunnels one is aware of. If one is aware of them it probably means one has configured their network to support that VPN. But in that case why filter (all) the packets involved? Thanks, Mark