Subject: QoS for BGP/MPLS VPNs in 2547bis

From: "Reddy, Vikram" <[email-masked]>
Date: Fri, 8 Mar 2002 06:01:35 -0500

Hi,

In 2547bis there is no mechanism to specify the QoS parameters
which we want to give for a VPN.

One possible way is to use the parameter VPN-ID and associate
it with a set of QoS parameters.

But 2547bis does not specify a mechanism for distributing the VPN-ID.
If we want to use the VPN-ID then we must depend on an external mechanism to
distribute the VPN-ID in the network.

But, even if we have an external mechanism to distribute the VPN-ID,
if we want to associate a VPN with certain QoS and want the data 
traffic for that VPN to receive that QOS, it would be possible only 
if there is a VPN-ID attached with the route advertisement.

Similarly there could be other attributes (other than QoS parameters)
which we may want to associate with a VPN and be able to use them on a
per-VPN basis.

So what is the solution if I want to associate routes with the VPNs they
belong and give
them the QoS (and other properties ) they are entitled to?

It would be useful if BGP route advertisements also attach the VPN-ID 
along with the prefix. We can configure each VRF with a VPN-ID and 
attach it to all the route advertisements.

When a service provider configures a VRF and associates it with a VPN-ID
he should also specify the QoS parameters which he wants to give to the
traffic
flows of that VPN (If the VRFs import policies are configured to receive
routes
from multiple VPNs,  he can specify the QoS for each VPN).

When a route is received from a remote PE and it matches with the import
RT of the VRF, an LSP must be found (or established/modified) to accomodate
the QoS
parameters configured for the VPN-ID received in the advertisement 
and the VRF entry made with that LSP tunnel label as the outer label.

An RT does not correspond with a VPN. Therefore the use of RT for mapping 
to QoS would not serve our purpose.

Please comment.
Vikram Reddy.

---

From: "Metz, Eduard" <[email-masked]>
Date: Fri, 8 Mar 2002 13:03:35 +0100

Do you want to apply a specific QoS policy to an entire VPN, or to a set of
routes within that VPN (possibly with different QoS policy for different
routes)?

In general you could do the following wrt QoS and VPN (I assume DIFFSERV):
- map DSCP  (or EXP in case of carriers-carrier) of incoming traffic to MPLS
EXP field;
- classify and mark incoming traffic and then do above;
- create multiple TE tunnels between PE-s using different IP endpoints for
each PE, and set BGP NextHop to particular tunnel endpoint based on QoS
policy you want to apply (you can do this for an entire VPN or routes within
a VPN).

I think all these can be done today. I'm not sure if you could automate the
third option (which seems to be what you are after) by e.g. tagging routes
with a specific community based on which PE-s apply a QoS policy to the
traffic corresponding to that route. Also I'm not sure whether such would be
a local, implementation specific thing or something that should be described
in a draft/rfc.

Hope this helps.

cheers,
	Eduard

> -----Original Message-----
> From: Reddy, Vikram [mailto:[email-masked]]
> Sent: Friday, 08 March, 2002 12:02
> To: [email-masked]; [email-masked]
> Cc: [email-masked]'; [email-masked]'
> Subject: QoS for BGP/MPLS VPNs in 2547bis
> 
> 
> Hi,
>

---

From: "Metz, Eduard" <[email-masked]>
Date: Fri, 8 Mar 2002 15:18:10 +0100

see inline,

Eduard

> My requirement is to be able to apply QoS to an entire VPN and to
> be able to do it automatically. No manual configuring should be 
> done for each route.

Okay, so you want to tag all VPN traffic as e.g. AF31? Or you want to do
something else?

> We must also be able to reserve QoS dynamically when a the 
> first route 
> for the VPN is reserved and must be able to give all the 
> routes learnt later
> in the VPN the same QoS.
> 

What do you mean with "reserve"?

> RT -> QoS mapping would be sufficient for a subset of routes.
> 

Above you state "entire VPN", here it is "subset of routes". Do you want to
attribute QoS parameters to routes or to the VPN?

> 
> In the first and second scenarios, of mapping DSCP or 
> classifying, yes you
> can do that
> to the data traffic.
> But when and where is the actual reservation for that traffic 
> done on the
> LSP Tunnel
> if we want guaranteed end-end QoS. 

You engineer your network such that you meet the requirements.

You do not need to do reservations perse. Proper capacity planning and
network engineering should do the trick. Making reservations could be used
as a tool to do capacity planning.

> And then, how do you place this traffic on the LSP on which you have
> reserved
> QoS, because the VRF or classifier must be programmed with 
> the LSP label and
> then 
> is a route accepted and traffic to the route is placed on 
> that particular
> LSP.

As the MPLS packets will inherit the QoS characteristics of the data
traffic, and there is no need for reservations, above is automagic.

> 
> The third method said is not totally clear to me. Are you suggesting
> that we use different virtual Ip addresses for the same PE router
> and give different BGP Next hop based on the QoS.
> Objections:
> 1) Unnecessary, extra information in the IGP.
> 2) Even if this is done, how does the ingress PE node know 
>    next hop -> Qos mapping.

Each next-hop is reachable through seperate TE tunnel with specific QoS
characteristics. So the ingress PE will match the traffic against a route,
which again is related to a BGP nexthop to which the traffic gets forwarded.
In a sense the nexthop address determines the QoS in this case.

> 3) It is the sender who should decide on the QoS for the 
> traffic (ingress
>    PE in our case). 
> 

Yep.

> 
> Since 2547bis does not provide anything to uniquely identify a VPN 
> and to identify traffic belonging to the VPN, there probably should
> be an extension/draft yo include that.
> VPN-VR does allow us to uniquely identify a VPN based on VPN-ID.
> This will give us more control on the policies we want to apply to the
> VPN.
> 

I'm not sure what the VPNID would give you here. What kind of attributes /
policies would you attach to a VPNID?

> Vikram.
> From: Metz, Eduard [mailto:[email-masked]]
> Sent: Friday, March 08, 2002 4:04 AM
> To: 'Reddy, Vikram'; [email-masked]; [email-masked]
> Subject: RE: QoS for BGP/MPLS VPNs in 2547bis
> 
> 
>

---

From: [email-masked]
Date: Mon, 11 Mar 2002 09:51:36 -0000

Robert,

There is a further aspect you should take into account here (I recall you/I
discussing this some time ago, and just having to agree/conclude 'its an
issue/problem'):

-	From a performance specification perspective, QoS is quite different
to availability.  There is no relationship between a pkt's QoS forwarding
requirments and its 'importance', ie its survivability requirements under
network resource reduction, such as network failures (vis-a-vis other pkts
of the same or different DS class in the same or different VPN).  Hence,
whether (for example) a voice application is mission critical or not, it has
to go EF class to meet (up-state) jitter transfer requirements.

-	I agree it makes sense to have similar QoS forwarding behaviour at
the pkt level across a network, but this does not necessarily mean that all
the VPNs supported must have identical availability SLAs.

-	QoS behaviour is conveyed at the pkt level.....but 'survivability'
behaviour cannot, this needs applying at the LSP level (and IMO this should
also be decoupled from the specific traffic/DS class types being carried at
any epoch both within a given VPN *and* across the total population of
VPNs).

-	the use of mp2p LDP LSPs and like-QoS-class merging across all VPNs
means the above now becomes impossible......as QoS and survivability become
'merged' and can't be decoupled across VPNs.

-	final observation.....QoS performance measurements only have any
sense when the network trail they are being applied to is in the available
state.  I hope this is obvious, but a corollary of this observation is that
one has to specify availability behaviour (ie entry/exit criteria), and in
turn this also means specifying things like defects (ie their entry/exit
criteria and consequent actions).  Further, since an operator/customer needs
consistent behaviour wrt to these parameters across manufacturers/operators
(respectively) (note - not their *objectives*, that is up to the
customer/operator to specify/provide), they also need to be standardised.
This has been addressed for p2p LSPs in Y.1710 (requirements) and Y.1711
(mechanisms) as some may already know.

regards, Neil

> From: Robert Raszuk [mailto:[email-masked]]
> Sent: 09 March 2002 14:10
> To: Reddy, Vikram
> Cc: 'Metz, Eduard'; [email-masked]; [email-masked];
> [email-masked]'; [email-masked]'
> Subject: Re: QoS for BGP/MPLS VPNs in 2547bis
> 
> 
> Reddy,
> 
> Per incomming interface EXP bit setting is possible at least in both
> commercial MPLS-VPN implementations I am familiar with. 
> 
> Giving QoS to the _routes_ is not a new concept. Why don't you use
> regular qos policy propagation with bgp for all VPN routes or a subset
> of those.
> 
> Appling different QoS per VPN is a pretty bad idea in itself. 
> 
> Now I am not sure if you are going to use LDP in the core or full mesh
> of PE-PE traffic engineer tunnels. Both ways are possible to achive
> decent diffserv with current 2547bis draft btw.
> 
> Could you be a bit more specific how you are going to use 
> this VPNID, in
> particular how this VPN-ID will help you to identify the vpn data
> belonging to this or different VPN for a selective qos treatment ?
> 
> R.
>

---

From: [email-masked]
Date: Mon, 11 Mar 2002 12:17:58 -0000

> > It may not be very scalable, but in fact I think one of 
> > the main requirements of VPN is to decouple the QoS of 
> > customers. Sonmething that probably requires per-customer queuing.
> > 
> > -Shahram
> 
> Well in almost all practical scenarios I met SP/ISP will not offer per
> customer queuing. Instead it will offer per customer's application
> queueing - the difference is very significant. And as an example it
> should not matter for customer A if his VoIP packets are 
> transported in
> the same diffserv pipe with VoIP packets belonging to 
> different customer
> B as long as both of them get what they have paid for.
> 
> Rgs,
> R.
Robert...hopefully you will have seen my last posting on this.  The basic
problem with the above is in the case of failure whose VoIP traffic
survives?  Merging like traffic types is fine for 'public' services, but in
the case of 'private' VPNs I don't understand how one can offer robust
survivability assurances.
BTW - for some types of VPN customer the behaviour you describe may be
adequate, but it may not be for others......they might want VPN
survivability assurances that are not a function of the traffic active at
any epoch (and with like-DS-class merging across all VPNs, then VPN traffic
survivability becomes a function of all VPN traffic at any epoch, not just
the VPN under consideration).  Hence, its not clear to me how one can offer
robust SLAs here.  But if you know how to do this then I would like to hear
it.

regards, Neil

---

From: "Metz, Eduard" <[email-masked]>
Date: Mon, 11 Mar 2002 13:55:06 +0100

> survivability assurances.

If merging of traffic is not fine for 'private' services, how would you
deliver these? Build seperate networks (at the physical / fiber or
transmission layer)?

Wrt survivability: which part of the network is the most significant factor
in service availability? I would guess network access, and service specific
elements (CPEs, VoIP gateway etc). The backbone should cater for the most
robust survivability assurances anyway, assuming it is a shared network, and
not the seperated one above (btw: to me it seems easier as well to provide a
high-level of robustness to all traffic instead to some traffic). So
probably the gain in differentiating in survivability in the core is much
less than when differentiating in network access (e.g. redundant tails) or
service specific elements (redundant CPEs or gateways).

cheers,
	Eduard

ps when does survivability become a function of the traffic (and how would
that function look like? more traffic => less survivability, or if
traffic=typeX, survivability=off?)

---

From: [email-masked]
Date: Mon, 11 Mar 2002 14:40:08 -0000

Thanks Eduard, reply in line.  regards, Neil
<snip>
> deliver these? Build seperate networks (at the physical / fiber or
NH=> It depends on the nature of the 'VPN' the customer wants and is
prepared to pay for.  Some do indeed require these be provided off L1
technologies since the BW and SLA requirements are very high.  Others are
happy with less robustly defined VPN services and perhaps want to take a
fully manage L2/3 VPN service.  Some want to build/run their own L3 network
and only want a L2 service from the SP.  etc.
> service specific elements (redundant CPEs or gateways).
NH=> Yes you are right that access is critical here....its also the largest
cost aspect and also the place where QoS demands are the hardest to provide
(which is why there is still a great deal of ATM here).  However, you should
not overlook other factors....esp those having common-mode failure
charactersistics.  In rfc2547 all VPNs are dependent on BGP4.....so one
hopes the code and the platforms it runs on are robust and failure tolerant.
Further, use of LDP as a server level of LSPs to the higher VPN LSPs does
require overengineering of the network.....this may or may not be
acceptable, it depends on factors such as the traffic mix, desired level of
utilisation (something people are paying increasing attention to) and
whether customers understand, and are prepared to accept, operators cannot
provide absolutely solid SLAs.  If so then fine, if not then we will need
alternative solutions.  I think with VPNs there is no magic/single
answer...it largely depends on what the customer wants and is prepared to
pay for.

> traffic=typeX, survivability=off?)
NH=> A cnls network mutates failures into QoS hits, and attempts to maintain
connectivity for all users.  This is how it is designed to operate and its
good model for certain types of traffic.  However, the degree of tolerance
to resource reduction is a function of the application.  Voice is different
to video is different to email etc.....and even for traffic of the same type
its not obvious (at the pkt) level which pkts are really more mission
critical than others (however, there is a distinction here between 'public'
and 'private' network services, since in the former it is valid to assume
all traffic is alike wrt importance).  If we just have 1 class of traffic,
call it BE, then we get a uniform resource reduction for all users in the
region of the failure.  If we have several classes (ie DS) then the resource
reduction has to be weighted/shared somehow amongst these classes.  You
might say let's give EF the lion's share of whatever resource remains since
it can't tolerate delay.  But what if the application here is 'office
gossip' and this was taking resource away from a more business critical
voice call (also using EF) or a more business crtitical data application
using an AF class....either of which may be in the same or a different VPN?
This may not be a problem if the non-critical EF traffic ratio (in this
example) is low on all links.....but what if this is not always true, or
perhaps there is a large take-off in video or whatever at some point, ie the
traffic patterns change?   Currently I guess most operators overengineer
their networks to cater for these issues....and maybe this is an adequate
response in many cases?  The corollary of overengineering is that DS-classes
tend to look alike wrt up-state behaviour.  And of course there are also
questions (esp thesedays) of how efficently one is using network
resources.....and for some types of VPN based on say FR significant
overbooking of the resource was/is very common (though please note that one
can still assign survivability on failure independent of this).  I also
suspect that when many customers buy a VPN they don't expect the
survivability of their traffic to be dependent on someone else's VPN
traffic.  So, in conclusion, whilst 'shared' VPNs might be OK for many
customers, for some others it won't be....so I think we can't ignore this
group.

---

From: Shahram Davari <[email-masked]>
Date: Wed, 13 Mar 2002 09:56:06 -0800

Hi Eric,

I think Vikram was asking for QoS signaling in the LDP case.

-Shahram

> From: Eric Rosen [mailto:[email-masked]]
> Sent: Wednesday, March 13, 2002 12:29 PM
> To: Reddy, Vikram
> Cc: [email-masked]'; [email-masked]; [email-masked]
> 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: Shahram Davari <[email-masked]>
Date: Wed, 13 Mar 2002 11:13:36 -0800

Vikram,

With LDP, the only QoS signaling you could do is Diffserv without BW reservation. Please check section 6.4.1 and 6.4.2 of the following draft:

http://www.ietf.org/internet-drafts/draft-ietf-mpls-diff-ext-09.txt

It gives you the procedure to signal QoS (Diffserv classes) with LDP.

The QoS-enabled transport tunnels are not established per-VPN, rather they can be shared between VPNs. So there is no need to signal the VPN-ID. Only the ingress LSR needs to know the QoS requirement of the VPN traffic and could assign them to proper LSPs and mark their EXP field appropriately.

-Shahram 

> From: Shahram Davari 
> Sent: Wednesday, March 13, 2002 12:56 PM
> To: [email-masked]'; Reddy, Vikram

---

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

Hi Shahram,

I was talking about QoS signaling using RSVP-TE. Also, I was talking about 
cases where reservation is made on every LSR.

Vikram

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

Hi Eric,

-Shahram

---

From: [email-masked]
Date: Thu, 14 Mar 2002 07:43:39 -0000

Vikram,

How are you proposing to relate QoS and availability on these VPNs?  QoS
behaviour only has any sense when the trails that form the topology of the
VPN are in the 'up-state', so I assume you have considered the need to
address this?

regards, Neil

> Sent: 14 March 2002 06:12
> To: 'Shahram Davari'; [email-masked]'; Reddy, Vikram

---

From: [email-masked]
Date: Thu, 14 Mar 2002 10:32:55 +0100

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.
> 
> 
> 
> Sent: Wednesday, March 13, 2002 9:29 AM
> To: Reddy, Vikram
> Vikram> When MPLS tunnels are set up between VRs belonging to a VPN, use
> If this is the functionality you seek in the context of 2547bis, I don't see
> 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

-- 
+===========================================================+
| 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: "Reddy, Vikram" <[email-masked]>
Date: Thu, 14 Mar 2002 06:54:44 -0500

Hi Neil,

I'm sorry, I am not clear about what you are mean. Could you please 
re-phrase your question?
If you are talking about the bandwidth , then I would think that it is the 
responsibility of the Service Provider to ensure that there is enough
bandwidth 
available in his network before selling his VPN with QoS.
Also, it is not compulsory that he has to provide a certain level
of QoS for each VPN. He can configure QoS=0 (BE) if the customer
doesn't wan't to pay for QoS.

I am just telling what the draft says about the requirement for L3VPNs
i.e the SP being able to provide per VPN QoS.

Thanks,
Vikram.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 13, 2002 11:44 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: QoS for BGP/MPLS VPNs in 2547bis 

Vikram,

regards, Neil

---

From: [email-masked]
Date: Thu, 14 Mar 2002 13:57:25 +0100

Hello Vikram,

> 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.

I agree. I was not saying 'special VPNs' don't need QoS. I was just
saying that I think that wrt QoS there's no difference between VR-based
VPN solutions and 2547-based solutions.

> 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. 

Hmm. I'm lost again :-)

In the VR-case, do you have one VR for the intranet and one VR for the
extranet ? If so, then you'll have the same case (and eventually
problem) as the 2547 solution with 2-VRF and multiple sub-interfaces, no
? what's the difference ?

Or do you have only one VR for both intranet and extranet ? Then you'll
end up with the same situation as when you configure multiple import RTs
per VRF in 2547.

> Based on the session on which the routes were
> learnt, he can apply the QoS configured for the VPN.

If you can do it based on the session on which the routes were learnt,
you can also do it based on the RT attribute that the BGP route was sent
with, no ?

> 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?

I just don't see what the difference is when you would try the same with
VR-based VPNs ? either you have multiple VRFs, but then you also have
your constraint on the CE; or you have only one VR, and you'll end up
with routes that you want to give different QoS, in the same VR.

Can you please clarify ?

Jeremy.

---

From: "Reddy, Vikram" <[email-masked]>
Date: Thu, 14 Mar 2002 08:32:19 -0500

Please see inline.....Tag VIK:

PS: Please note that I am not at all suggesting that VPN-VR is better/worse
compared
    to 2547bis. I am just telling that when it comes to identifying a
particular
    VPN and applying QoS/other Policies per VPN, VPN-VR is simpler.
    We can always put the burden on the administrator and have him maintain 
    QoS info based on a combination of RD/RTs/prefixes and achieve VPN level
    QoS. 

Vikram

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

Hello Vikram,

Hmm. I'm lost again :-)

VIK: The same VR has session with both intranet and extranet.
     But the difference is, when the membership info is distributed
     by BGP, there is an attribute called VPN-ID which comes with 
     a label(used as inner label in the stack) and a PE router address.
     This membership info advertsement is received by backbone VR on the PE.
     If a particular VR is interested in importing routes from
     this VPN then this info is passed to the VR by the backbone 
     VR( info means VPN-ID,label,PE address).
     When this VR receives the information, it knows which VPN
     this info corresponds to, based on VPN-ID. Based on the
     VPN we can get the corresponding QoS, setup/modify an LSP with that 
     QoS to the PE, use the inner label and the outer MPLS label, establish
     a BGP session with that neighbor. Now all the routes received from 
     this peer belong to a VPN and will get this QoS.

     In the case of 2547 you do not have a VPN-ID. So you cannot have
     the seperation of associating routes with a VPN.

VIK:  But RT -> VPN mapping is not 1-1. But, session in  VPN-VR to VPN
(based on VPN-ID)
      is 1-1.  This is one of the many problems I mentioned in the  mail I
wrote to
      Mr.Eric Rosen about associating RT-> QoS. Please see that what other
problems
      with RT->QoS I feel there are.

VIK:  You can have one VR with one interface, placing no requirement on the
      CE and have him send the packets to the VR. In the FIB of the VR
      we already have a stack of labels with the route. The outer 
      label corresponds to an LSP on which we have reserved bandwidth 
      along the LSRs. The outer label itself is enough to 
      take the data packet along the path with reserved bandwidth.
      Do FEC, attach the labels and send the packets and they will receieve
the QoS for the LSP.

Can you please clarify ?

Jeremy.

---

From: Shahram Davari <[email-masked]>
Date: Thu, 14 Mar 2002 05:55:54 -0800

Hi,

Sorry my misunderstanding. Since RFC2547bis is focused on LDP, I thought you are asking about LDP. Then your answer is what Eric gave.

-Shahram

> Sent: Thursday, March 14, 2002 1:12 AM
> To: Shahram Davari; [email-masked]'; Reddy, Vikram