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

From: "Reddy, Vikram" <[email-masked]>
Date: Thu, 14 Mar 2002 06:30:49 -0500

Hi Jeremy,

draft-ietf-ppvpn-requirements-04.txt Section 4.5 says that 

   "QoS is expected to be an important aspect of a PPVPN service for some 
   customers. QoS requirements cover scenarios involving an intranet, an 
   extranet, as well as shared access between a VPN site and the 
   Internet. "
Also Section 4.13 of the same draft also says that the csutomers have a 
number of reasons for having hybrid VPNs .

So even if Extranets, hybrid VPNs etc. may be special, the QoS requirements
of these special configurations should be taken into consideration.

For Example: It is not unreasonable to expect to give a certain QoS to my
intranet traffic
and a different QoS to my extranet traffic.

In VPN-VR it is possible to provide different QoS to intranet traffic 
and extranet traffic because there is a VR has a different BGP session
for an intranet VR and an extranet VR. A VR also knows which session is
a belongs to the intranet (same VPN) and which session belongs
to the extranet. Based on the session on which the routes were 
learnt, he can apply the QoS configured for the VPN.

I agree with you that by having different VRF per extranet/intranet 
you can have different QoS by configuring QoS per VRF.
But this places a constraint on the CE that he should support VLANs.
Also, if you want the VRF to be part of 10 extranets, would you 
configure 10 VRFs and 10 sub-interfaces?

Vikram.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, March 14, 2002 1:33 AM
To: Reddy, Vikram
Cc: [email-masked]; [email-masked]
Subject: Re: QoS for BGP/MPLS VPNs in 2547bis

Vikram,

I don't really see what you mean. You're not obliged to import routes
from different RT's in a VRF. In fact, you would only do this in special
situations (extranets, merging of VPNs ...). 

In normal situations (CUG-like VPNs), you would assign one RT to a VPN
(import RT = export RT (= VPN-ID)). So the RT has the same functionality
as a VPN-ID. This way, VR-based VPNs and 2547-based VPNs are identical
wrt per-VPN QoS. You can configure per-VPN QoS based on the VRF/RT.

If you assign more than one import RT to a VRF, you're building more
complex VPNs, and that's an extra feature compared to a purely VPN-ID
based mechanism.

In these more complex configurations, it's up to you to decide what you
call "the VPN" and "per-VPN QoS".

If you really want a site to be in multiple VPNs, one possibility is to
import routes with different RTs in its VRF (like in your example). If
you want to configure per-VPN QoS on a RT/VRF basis, alternatively you
could attach your site to two different VRFs (each with only one import
target), via two sub-interfaces.

Am I missing the issue ?

regards,

Jeremy.

"Reddy, Vikram" wrote:
> 
> 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?
> 

-- 
+===========================================================+
| Jeremy De Clercq                                          |
| Network Strategy Group                                    |
| Alcatel                                                   |
| Francis Wellesplein 1         phone: +32 (0)3 240 4752    |
| B-2018 Antwerpen              fax:   +32 (0)3 240 4888    |
| Belgium                       [email-masked] |
+===========================================================+

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 14 Mar 2002 16:49:41 +0100

> of these special configurations should be taken into consideration.

So what is the problem - nobody says that you must put all packets which
are comming to a given VRF the same QoS treatment. Nobody also says that
you must map them to a single TE tunnel or apply a single EXP field for
scheduling in the LDP environment. 

It is not only posible but also even actually done today so I am even
sure what this entire discussion is about ?

R.