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