Subject: RE: QoS for BGP/MPLS VPNs in 2547bis

From: "Reddy, Vikram" <[email-masked]>
Date: Thu, 14 Mar 2002 01:04:51 -0500

Hi Eric,

You have not misunderstood the functionality I was talking
about. The only problem with the approach you are suggesting
is since a VRF could possibly import routes from multiple VPNs,
associating VRFs with certain QoS does not exactly give the
flexibility of having different QoS per VPN.

For Example:
If VRF1 
exports RT=Red (exports routes belonging to VPN with RT=Red) 
imports routes with RT=Red,Blue,Green.

If it wants to give QoS1 to routes with RT=Red, QoS2 to routes
with RT=Blue, QoS3 to routes with RT=Green the approach you mentioned
would not work.

Clearly VRF->QoS mapping does not give us QoS per VPN.
The example I mentioned above seems to point naturally to the solution
of associating an RT with QoS.
But the problems I have with RT->QoS mapping are
1) It is possible that a VPN could be associated with multiple RTs.
   and RT -> VPN mapping is not 1-1. Therefore, to make RT the equivalent
   of VPN-ID(which is associated with a single VPN) is not correct.
2) Even if we decide to give QoS based on RT, there would be too much
   configuration detail because of the possibility of
   having multiple RTs per VPN (#of RTs >> #of VPNs).
3) What if a route has multiple RTs, matches multiple import RTs for 
   the VRF, which RT do you use for QoS mapping.

The reason I am bringing up the issue of needing to have VPN per QoS 
is the draft : draft-ietf-ppvpn-requirements-04.txt
which talks about the SP being able to provide pipe model(site-site)\
QoS per VPN, both Diffserv and Intserv.

Also the draft :draft-ietf-ppvpn-vpn-vr-02.txt
in section 2.3 Quality of Service 
has the following sentence. 
      Therefore, quality of service (policing, shaping, classification, 
      and scheduling) SHOULD be configurable on a per-VPN basis. 

Thanks,
Vikram.

-----Original Message-----
From: Eric Rosen [mailto:[email-masked]]
Sent: Wednesday, March 13, 2002 9:29 AM
To: Reddy, Vikram
Cc: [email-masked]'; [email-masked]; [email-masked]
Subject: Re: QoS for BGP/MPLS VPNs in 2547bis 

Vikram> In the VPN-VR model QoS per VPN is achieved as follows.
Vikram> When MPLS tunnels are set up between VRs belonging to a VPN, use
Vikram> the configured QoS for the VPN to set up the LSP.

If this is the functionality you seek in the context of 2547bis, I don't see
why you think you need any protocol extensions to provide it.

The VRFs corresponding to a particular  VPN would be configured for QoS, and
when a VPN-IP route  arrives with a new BGP next hop,  RSVP-TE could be used
to set up  a QoS-enabled tunnel to  that next hop, and this  tunnel could be
made  to be the  outgoing interface  for all  packets from  that VRF  to the
remote tunnel endpoint. 

Have I  misunderstood the functionality  you're discussing?  If not,  why do
you think you need protocol extensions?

---

From: Eric Rosen <[email-masked]>
Date: Thu, 14 Mar 2002 15:19:38 -0500

Vikram> If VRF1 exports RT=Red (exports routes belonging to VPN with RT=Red)
Vikram> imports routes with RT=Red,Blue,Green. 

Vikram> If it wants to give QoS1  to routes with RT=Red, QoS2 to routes with
Vikram> RT=Blue,  QoS3 to routes  with RT=Green  the approach  you mentioned
Vikram> would not work. 

The obvious extension though would be  that when you configure VRF1 with its
Import Targets, you specify a QoS  for each Import Target.  Then only routes
which  arrive with  the  corresponding  Route Target  would  get the  proper
RSVP-TE tunnel as their next hop interfaces.