Network Working Group Jeremy De Clercq INTERNET DRAFT Alcatel February 2003 Expires August, 2003 QoS considerations for L3 PPVPNs Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. Abstract Although QoS is identified as a very important requirement for L3 PPVPNs (see for example [PPVPN-REQ]), the proposed L3 PPVPN solutions ([2547bis], [VR], [CE-based]) have paid very little attention to describing how the proposed approach fulfills the QoS requirements. This document explores different points of view, describes dependencies and orthogonalities, and details a number of solutions and guidelines. Table of Contents De Clercq Expires August 2003 [Page 1] Internet Draft draft-declercq-ppvpn-l3vpn-qos-00.txt February 2003 0. Sub-IP Area Section ......................................... 2 1. Introduction ................................................ 3 2. Potential QoS-related issues with L3 PPVPNs ................. 4 2.1 Default use of LDP-DU and LSP merge ......................... 4 2.2 Default use of one PE-PE tunnel for all QoS classes and for all VPNs .................................................... 6 2.3 Use of Penultimate Hop Popping (PHP) ........................ 8 2.4 BGP Signalling .............................................. 9 2.5 PPVPNs in non-MPLS networks ................................. 11 3. Example ..................................................... 12 3.1 QoS pre-provisioning of SP's network ........................ 12 3.2 VPN SLS and Configuration of QoS-enabled L3 PPVPN ........... 12 3.3 Adding a VPN site ........................................... 13 4. Conclusion .................................................. 13 5. Acknowledgements ............................................ 14 6. References .................................................. 14 7. Authors' Addresses .......................................... 14 0. SubIP-Area Section SUMMARY This document acknowledges the fact that QoS is a very important part of a VPN service, and demonstrates that for L3 VPNs, offering QoS to the VPN customers may be seen as a rather orthogonal issue from building the VPN topology and managing the connectivity. Nevertheless, some potential issues are discussed and possible solutions or prefered practices are identified. It is explained how to make advantage of the MPLS-DiffServ mechanisms to differentiate between customers and traffic classes (including level of traffic protection). It is also explained that establishing VR-to-VR non- multiplexed core LSPs is nor scalable nor necessary. In addition, the impact of the possible use of PHP is identified and the prefered way to handle this is explained. Finally, we state that the use of BGP to signal intra-domain per-VPN QoS parameters is not useful. RELATED DOCUMENTS See References section (especially [PPVPN-REQ], [2547bis], [VR]). WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK PPVPN box. WHY IS IT TARGETED AT THIS WG This document discusses PPVPN-specific QoS matters. De Clercq Expires August 2003 [Page 2] Internet Draft draft-declercq-ppvpn-l3vpn-qos-00.txt February 2003 JUSTIFICATION QoS is identified as a very important requirement for L3 PPVPNs (see for example [PPVPN-REQ]), while the proposed L3 PPVPN solution documents have paid very little attention to describing how the proposed approach fulfills the QoS requirements. 1. Introduction Although QoS is identified as a very important requirement for L3 PPVPNs (see for example [PPVPN-REQ]), the proposed L3 PPVPN solutions ([2547bis], [VR], [CE-based]) have paid very little attention to describing how the proposed approach fulfills the QoS requirements. There are a number of possible explanations for this apparent contradiction: (i) provisioning an IP VPN over a shared backbone on one hand and offering Differentiated treatment and QoS guarantees to traffic flows over a SP's backbone on the other hand are orthogonal issues (this would mean that SP's offering VPN services using the approaches defined in the PPVPN WG can add QoS assurances to these VPNs using QoS mechanisms defined elsewhere), (ii) the VPN solutions have focussed on providing restricted connectivity first and will elaborate on the QoS issue later, (iii) the discussed solutions do not acknowledge QoS as an important requirement for VPNs and are happy with a solution for Best Effort VPNs. This document assumes (i) or (ii) is applicable and explores different points of view, describes dependencies and orthogonalities, and details a number of solutions. When QoS guarantees are offered as a service to VPN customers, the details of this offering are described in the SLS between the SP and the VPN customer (the Service Level Specification is the technical part of the Service Level Agreement). Such an SLS will describe the QoS guarantees (in terms of bandwidth, delay, jitter, drop probability, etc.) and the availability/survivability guarantees of a VPN customer's various types of traffic. As a VPN consists of a set of sites attached to a SP's core network, a VPN SLS is often described as a collection of pipe and/or hose service specifications. On one hand, VPNs segregate the traffic of different customers (this means for example that the behaviour of one VPN customer must not affect the traffic of other VPN customers served by the same SP backbone), and on the other hand, QoS/CoS segregates the different types of traffic travelling over a network as to treat them appropriately. And of course, one VPN customer may send different types of traffic. Important to note is that, as SLSs are VPN customer-specific, the same type of traffic belonging to different VPN customers may need to be treated differently in the SP's core network (both with regards to QoS and availability/survivability). De Clercq Expires August 2003 [Page 3] Internet Draft draft-declercq-ppvpn-l3vpn-qos-00.txt February 2003 This means that the traffic class (a traffic class contains all the traffic from a certain network portion that will be QoS/CoS treated identically in that specific portion of the network) of a specific packet in the SP's core network is a function of (i) the traffic class of a packet in the customer's network and (ii) the VPN the packet belongs to. Instantiating a pipe or hose SLS in a provider's core network requires specific provisioning of some network elements and possibly specific QoS-signalling in the core network. One important question is whether these QoS provisioning actions are "compatible" with the VPN provisioning and auto-discovery mechanisms. Indeed, the current L3 PPVPN approaches have been designed as to optimize scalability (in usage of core network resources (e.g. "no per-VPN state in the core"), in provisioning burden (e.g. "VPN membership auto- discovery"), etc.). So the question is whether the provisioning of QoS parameters (dictated by the SLS), that is often a task that is distributed over multiple network elements, can be optimized as to fit within the scalable local VPN provisioning tasks. A last initial consideration is that the default VPN signalling used by the SP is a point-to-multipoint signalling that has a per VPN- route granularity (or per set of destination addresses) in [2547bis]. This in contradiction to QoS signalling that typically is a point- to-point signalling with a per-flow (or per-aggregate flows - type of traffic) granularity. Section 2 of this document discusses several "potential QoS-related issues with L3 PPVPNs": the goal is to identify which issues can be solved using (or combining) existing mechanisms, which issues have been raised but are irrelevant and which issues could benefit from the definition of additional protocol extensions or specifications. Section 3 gives an example of the provisioning and operation of a QoS-enabled L3 PPVPN. Section 4 gives an overall conclusion. 2. Potential QoS-related issues with L3 PPVPNs 2.1 Default use of LDP-DU and LSP merge o description MPLS-based VPNs (e.g. [2547bis])use a two-label stack to forward packets accross the SP's backbone. The specification assumes that every PE knows which 'outer' label to push on data packets to make them reach a particular egress PE, identified by its /32 "BGP NEXT HOP". There is no requirement on how this PE-to-PE "tunnel LSP" is established. In order to improve interoperability, the specification states that every router MUST support LDP. Using De Clercq Expires August 2003 [Page 4] Internet Draft draft-declercq-ppvpn-l3vpn-qos-00.txt February 2003 LDP, the distribution of each router's /32 address into the core's IGP automatically results in the establishment of a full mesh of LSPs between PE devices (1 single LSP per direction between each pair of PE devices). Where applicable, these LSPs will be merged as to preserve the routers' label space as much as possible. In many aspects, an LDP-signalled MPLS core network behaves like an IP-forwarded core network. This is the case too for the QoS aspects: RFC3270 explains how to make an MPLS network DiffServ- aware. Although differentiated treatment of different classes of service is possible, LDP doesn't allow to explicitly signal bandwidth reservations, to establish traffic engineered paths or to establish multiple paths between the same destination with different levels of protection. o solution As was mentioned before, there is no requirement on the way the PE-PE LSPs are established: the routers must support LDP but may use e.g. RSVP-TE to establish traffic engineered LSPs with certain signalled bandwidth guarantees. In addition, nothing precludes a SP to establish more than one LSP per pair of PE devices (for a certain direction), and let the ingress decide which tunnel to use on a per-packet basis. Other architectures that use a traffic- engineered core in addition to a LDP-signalled scalable MPLS edge can prove to be very usefull too. Alternatively, in an intelligently over-provisioned network with under-utilized links (possibly using DiffServ for service differentiation), the overall performance of an LDP-established mesh may be high enough as to satisfy every customer's SLS. o impact Using traffic engineered/bandwidth guaranteed (RSVP-TE) LSPs from PE to PE instead of a full mesh of automatically established LDP LSPs results in a higher label consumption, an increase of the state maintained in the network elements and an increase of the signalling load for the SP's routers. Also the management burden may likely increase. These implications are orthogonal to the fact that MPLS VPNs is the service transported by the MPLS network, and has as such no impact on the VPN specification (e.g. [2547bis]). o conclusion By offering PPVPNs based on MPLS VPN approaches, a SP has the complete freedom to use the range of capabilities of the underlying MPLS network. BGP/MPLS VPNs need PE-to-PE tunnels. These tunnels may be automatically established using LDP (and De Clercq Expires August 2003 [Page 5] Internet Draft draft-declercq-ppvpn-l3vpn-qos-00.txt February 2003 eventually enhanced with DiffServ capabilities [3270]), or alternatively using RSVP-TE. The latter approach allows the SP to take advantage of the available traffic engineering, bandwidth reservation signalling and dedicated protection capabilities of RSVP-TE established LSPs. 2.2 Default use of one PE-PE tunnel for all QoS classes and for all VPNs o description In BGP/MPLS VPNs, VPN routes are distributed among PE devices using BGP. The BGP Route Target attribute identifies which VPN the routes belong to; the MPLS label carried with the routes in the BGP updates is the 'inner label' to be used for packets sent on these announced routes, and the BGP NEXT_HOP attribute identifies the egress PE for these routes. In the forwarding plane, when a site sends a packet to its attached PE, an IP destination address look-up in the associated VRF results in a 'inner label' and a NEXT_HOP address. Based on this NEXT_HOP address, the tunnel LSP to send the packet on is identified. As such, in the most simple and default implementation, the NEXT_HOP address uniquely identifies a PE to PE LSP. As such, all packets destined for destinations advertised by the egress PE will be sent on a particular LSP, independent of the VPN the packets belong to and independent of the class of service associated with the packets. This means that all traffic from all VPNs would be treated and protected equally. With one single LSP between two PEs, even when this LSP is associated with certain reserved resources, when congestion occurs, all traffic classes of all VPNs will be affected in a non-deterministic way. o solution (A) In order to accomplish a differentiated treatment, RFC 3270 can be used: the PE-PE LSPs can be E-LSPs (one LSP carries traffic from a set of BAs) or L-LSPs (one LSP carries traffic belonging to one PSC), with or without bandwidth reservations. Upon congestion, differentiated treatment for different classes of traffic will be applied. Using RFC3270, it is also possible (using multiple L-LSPs between a couple of PEs) to give different survivability assurances to different DiffServ classes. Using DiffServ E-LSPs and L-LSPs, possibly associated with explicit bandwidth reservations and specific protection characteristics per LSP, a SP can guarantee different specific levels of service for different classes of traffic between any two PE devices. In order to optimize the scalability of the De Clercq Expires August 2003 [Page 6] Internet Draft draft-declercq-ppvpn-l3vpn-qos-00.txt February 2003 architecture, it is of prime import to aggregate the traffic belonging to the same class of service and that is associated with the same survivability guarantees. Note that this class of service (and survivability class) is the class to which the packets are associated within the SP's core network. The SLS of every customer describes which treatment (service guarantees) will be associated with which traffic types. This is VPN-dependent: the same traffic type (e.g. with the same DSCP, or from the same application), belonging to different VPNs, may be associated with different service guarantees in the SP's core. As such, data packets that will be carried by the SP's network will be associated with a specific SP's traffic class, depending on (i) the VPN they belong to and (ii) the packet's "traffic type". The packet's traffic type may be identified by it's DSCP or alternatively by a combination of other fields (e.g. source and destination IP addresses, protocol, port numbers etc.). This means that, as an extreme example, based on the specifics of the considered SLSs, the 'gold' traffic of VPN-blue can be associated with the same SP's traffic class as the 'best effort' traffic from VPN-red. So the result is one ("traffic type"[in the context of one VPN] => "traffic class in the SP's network") translation table per VPN. In addition there will be one (<"traffic class in the SP's network", BGP NEXT_HOP> => <"outer MPLS label", EXP-bit setting, outgoing interface>) table per PE device. In the data forwarding plane, this means that, processing of a VPN packet in a VRF sent by a directly attached customer site will result in the identification of (i) 'inner label', (ii) BGP NEXT_HOP and (iii) "traffic class in the SP's network". Resolving the BGP NEXT_HOP and "traffic class in the SP's network" information will uniquely identify the 'tunnel label' to use and the setting of the EXP bits in that outer label. (B) An alternative way to differentiate traffic from different VPNs is to establish end-to-end bandwidth guaranteed VRF-to-VRF hop-by-hop LSPs. This would result in a one-label MPLS stack in the core network and is obviously a non-scalable solution. o impact The impact of using the approach described in (A) is that PE devices need to be able to implement different policies for mapping packets into traffic classes, depending on the VPN the packets belong to. The enforcement of customer SLSs implies the De Clercq Expires August 2003 [Page 7] Internet Draft draft-declercq-ppvpn-l3vpn-qos-00.txt February 2003 ability to establish per-VRF policers, shapers and markers in the PE device. There is no impact on the BGP/MPLS VPN or VR-based VPN specification. The impact of implementing something according to (B) is important: the scalability would drastically decrease (a very large amount of LSPs to maintain, the distribution of /32 addresses per VRF, etc.). This method contrasts with the separation of the "tunneling architecture" vs the "VPN architecture" as used by e.g. BGP/MPLS VPNs. As such (B) is not compatible with [2547bis], while it could be implemented in the [VR] framework. o conclusion By implementing differentiated treatment for a set of specified traffic classes in the SP's core network (using RFC3270 and/or using traffic engineered LSPs and/or using explicitely reserved bandwidth guarantees per LSP and/or using different protection rules for different LSPs between the same couple of PEs), and by defining VPN-dependent mappings for packets into these traffic classes (according to the VPN SLSs), a SP has all necessary freedom to fully support VPN- and traffic-dependent QoS guarantees. 2.3 Use of Penultimate Hop Popping (PHP) o description The use of PHP has implications on the way a DiffServ-aware MPLS network operates (see [3270]). Application of the "pipe model", that is intuitively the most appropriate model for a PPVPN service, is not possible. By applying the "pipe model" on the LSP (PE-to-PE) tunnel, the core network's DiffServ information would be lost at the egress PE in case of PHP. o solution As explained in [3270], the use of the "tunneling model" (pipe, short pipe or unified model) is configurable on a per "nested LSP" level: the DiffServ treatment of every label in the MPLS label stack can be according to a different "tunneling model". An important requirement for PPVPNs is that the VPN packet's eventual QoS marking (DSCP) can be transported transparantly over the SP's backbone. For a specific PE-to-PE LSP, if PHP is not used: De Clercq Expires August 2003 [Page 8] Internet Draft draft-declercq-ppvpn-l3vpn-qos-00.txt February 2003 - the "tunnel LSP" is allowed to operate in the "pipe model". In this scenario, the DiffServ treatment of the "inner label" may be ignored. Use of the EXP-bits of the "inner label" is TBD. - the "tunnel LSP" is allowed to operate in the "unified model". In this scenario, the "inner label" must operate in the "pipe model". - the "tunnel LSP" is allowed to operate in the "short pipe model". In this scenario, the "inner label" must operate in the "pipe model". For a specific PE-to-PE LSP, if PHP is used: - the "tunnel LSP" is NOT allowed to operate in the "pipe model", because the impact of the forwarding of the packet through the SP's network on the packet's DiffServ information would be lost at the penultimate hop and unusable to the egress PE. - the "tunnel LSP" is allowed to operate in the "unified model". In this scenario, the "inner label" must operate in the "pipe model". - the "tunnel LSP" is allowed to operate in the "short pipe model". In this scenario, the "inner label" must operate in the "pipe model". o conclusion The SP should make consistent choices with regards to the use of PHP and the use of the different "DiffServ tunneling models" at each depth of the MPLS label stack. 2.4 BGP Signalling o description In PE-based PPVPNs ([2547bis],[VR]), the addition of one new site to an existing VPN requires only local configuration at the PE to which the new site will be attached. The other PEs that serve the same VPN will auto-discover the presence of a new VPN site. This auto-discovery is BGP-based. On the other hand, the addition of a new VPN site that is associated with a guaranteed SLS will require the provisioning of QoS-specific attributes at the directly attached PE, but eventually also at other PEs. This would then compromize the "auto-discovery" mechanism and the "local De Clercq Expires August 2003 [Page 9] Internet Draft draft-declercq-ppvpn-l3vpn-qos-00.txt February 2003 provisioning only"-paradigm. o solution and impact In many situations, the addition of a VPN site with QoS guarantees will not require provisioning of other PE devices than the one to which the site is to be directly attached. Indeed, this is the case for the addition of a VPN site - that is associated with a hose (+funnel) SLS that doesn't contrast with the SLSs of the other existing sites in the same VPN (meaning that these SLS's don't need to be re-defined), - whose SLS guarantees (for the different types of traffic) can be assured by the SP's core network without re-provisioning of resources (as it "fits" within the pre-provisioned QoS trunks in the network; as identified e.g. by an admission control procedure on an aggregate level) Such a scenario can be assured by intelligent planning and network (pre-)provisioning. In some situations, the addition of one VPN site with QoS guarantees will require provisioning of other PE devices than the one to which the site is to be directly attached. For example, the addition of a new VPN site that is associated with a pipe SLS towards a particular other site will often require the provisioning of specific traffic conditioners at both the local PE and the peer PE. In some situations, where this exercice of distributed provisioning is a non-frequent task and/or only involves a restricted number of PEs, this is acceptable, in other situations this can translate to a large management burden for the SP. Intelligent network planning and pre-provisioning, combined with the definition of appropriate SLSs looks like the preferred approach. Alternatively, signalling could be used in order to dynamically communicate the QoS characteristics of the inter-site VPN traffic. Although BGP has become the default inter-PE VPN signalling protocol, it is not a good candidate to perform the discussed QoS signalling for a number of reasons: - (I-)BGP is a point-to-multipoint routing protocol: this means that all the peer PEs attached to a certain VPN will receive the same information; signalling QoS characteristics with such a De Clercq Expires August 2003 [Page 10] Internet Draft draft-declercq-ppvpn-l3vpn-qos-00.txt February 2003 mechanism would only be effective when the QoS parameters for all pairs would be identical for a specific VPN. As this only covers a small subset of the possible deployments, such a mechanism would not be very useful. - BGP signalling as used for VPNs has a per-route [2547bis] or a per-VR [VR] granularity. Adding QoS parameters to 2547bis-like BGP signalling would mean sending the QoS information with every exchange of reachability information, which is not efficient; adding QoS parameters to VR-like BGP signalling would apply on a VR-to-VR scope while different sites may be connected to the same VR and it is probable for customer SLSs to be defined on the granularity of site-to-site rather than VR-to-VR. In addition, BGP has no affinity with QoS signalling: the definition of the necessary extensions would require serious standardization efforts, and the interaction between a router's BGP process and the provisioning of signalled QoS attributes would need to be studied. An alternative solution would be to not to couple the VPN (topology and membership) signalling with an eventual QoS signalling. This would mean signalling VPN QoS characteristics (with e.g. RSVP) within the VPN, after the VPN topology has been created/discovered with the known VPN BGP mechanisms. o conclusion Intelligent network planning and pre-provisioning, combined with the definition of appropriate SLSs looks like the preferred approach. Using hose and funnel SLSs for IP VPNs looks like a natural fit, and eases the SP's provisioning tasks. The provisioning of QoS parameters associated with "pipe SLSs" is a feasible task in 'stable' environments (where additions of new sites is a non-frequent task). Signalling QoS attributes using the VPN BGP-based auto-discovery mechanisms does not seem appropriate. 2.5 PPVPNs in non-MPLS networks o description [2547-IP-GRE] describes how to deploy BGP/MPLS VPNs in a non-MPLS network, and [VR] does the same for VR-based VPNs. In both approaches, forwarding in the SP's core network is based on the IP addresses of the packets' "outer IP header". In such a deployment, the SP cannot take advantage of MPLS-specific features such as MPLS traffic engineering, fast protection and restauration De Clercq Expires August 2003 [Page 11] Internet Draft draft-declercq-ppvpn-l3vpn-qos-00.txt February 2003 mechanisms. On the other hand, many SPs may want to offer QoS VPNs over a non-MPLS, pure IP network. o solution A SP offering VPN services can provision and operate its IP backbone network in the same way as he does for other services that are associated with strict SLSs (e.g. by intelligent network dimensioning, traffic conditioning at the network edges and using DiffServ in the core network). The SP's IGP and lower layer technology will take care of routing traffic around network failures (the eventual disruption of user service should be taken into account in the SLS). The SP can use an approach such as described in section 2.2 for the mapping of user-defined traffic class to the traffic classes used in the SP's core. There is no such concept as PHP in an IP- tunneling environment (section 2.3). The same remarks for VPN signalling as described in section 2.4 apply for VPN services over non-MPLS core networks. 3. Example 3.1 QoS pre-provisioning of SP's network In a first phase, the SP will define the QoS classes and the protection levels to be used in its core network, independently of any customer SLS, and provision its routers, and define the PHBs and eventually establish the tunnel LSPs. For example the SP may choose to create a DiffServ-aware LDP-DU established LSP mesh to carry the (i) Best Effort, the (ii) low packet loss and the (iii) low delay and jitter classes, and in addition to that to establish traffic- engineered and protected RSVP-TE LSPs to carry the (iv) high availability and 'very strict SLS' traffic. The SP will also provision traffic conditioners at the network edges for the non-VPN traffic. 3.2 VPN SLS and Configuration of QoS-enabled L3 PPVPN An SLS will be defined when a new customer is added to the SP's network. This SLS will be based on customer input and finalized after negotiation with the SP. Before accepting the SLS, the SP will control wether its core network is able to support the described SLS without compromising the other services that the network currently supports (e.g. without introducing congestion that would affect priority traffic). If this is not the case, the SP may want to re- dimension its network or reject the customer's request. De Clercq Expires August 2003 [Page 12] Internet Draft draft-declercq-ppvpn-l3vpn-qos-00.txt February 2003 If the SLS is finally accepted, the SP will configure the VRFs in the affected PE routers (e.g. access connections, Route Target attributes, Route Distinguishers) and provision the QoS parameters (e.g. traffic conditioners in the PEs) according to the SLS. More precicely, the SP will define mappings between the customer's packets traffic types and the traffic classes it has defined in its core network ((i), .., (iv)), and then provision policers for these classes according to the agreed SLS. Every PE to which a new site is to be attached, is to be provisioned. 3.3 Adding a site Assume that at a later point in time, the VPN customer decides to add a new site to its VPN. After negotiation, an SLS will be associated with this new site. The SP will again control wether its network can support the SLS (possibly after re-dimensioning and provisioning) before accepting it. If the SLS is accepted, the SP will configure the necessary parameters (access connections, possibly RD, RT, etc.) at the PE to which the new site is to be attached, define the mappings and provision the local QoS parameters (traffic conditioners at that particular PE). If the SLS is such that no QoS provisioning at peering PEs is necessary (e.g. a compatible hose SLS), than the provisioning effort is done and remains a purely local effort. Alternatively, while the auto-discovery mechanism will make sure the other PEs will discover the new site, re-provisioning of QoS parameters at the other PEs might be necessary (e.g. for the addition of a guaranteed QoS pipe to a VPN). 4. Conclusion This document acknowledges the fact that QoS is a very important part of a VPN service, and demonstrates that for L3 VPNs, offering QoS to the VPN customers may be seen as a rather orthogonal issue from building the VPN topology and managing the connectivity. Nevertheless, some potential issues are discussed and possible solutions or prefered practices are identified. It is explained how to make advantage of the (MPLS-)DiffServ mechanisms to differentiate between customers and traffic classes (including level of traffic protection). It is also explained that establishing VR-to-VR non- multiplexed core LSPs is nor scalable nor necessary. In addition, the impact of the possible use of PHP is identified and the prefered way to handle this is explained. Finally, we state that the use of BGP to signal intra-domain per-L3VPN QoS parameters is not useful. De Clercq Expires August 2003 [Page 13] Internet Draft draft-declercq-ppvpn-l3vpn-qos-00.txt February 2003 5. Acknowledgements The author would like to thank the following persons for their valuable contributions to this document: Mustapha Aissaoui, Sven Van Den Bosch, Arnold Jansen. 6. References [CE-based] De Clercq, J. et al., "An Architecture for Provider Provisioned CE-based VPNs using IPsec", Work in Progress [FRAMEWORK] Callon, R. et al., "A Framework for Provider Provisioned Virtual Private Networks", draft-ietf-ppvpn-framework-0x.txt, Work in progress [PPVPN-REQ] Carugi, M., McDysan, D., "Service Requirements for Layer-3 Provider Provisioned VPNs", draft-ietf-ppvpn-requirements, Work in Progress [VR] Knight, P., et al., "Network-Based IP VPN Architecture using Virtual Routers", Work in Progress [2547bis] Rosen, E., et al., "BGP/MPLS VPNs", Work in Progress 7. Authors' Addresses Jeremy De Clercq Alcatel Fr. Wellesplein 1, 2018 Antwerpen, Belgium E-mail: jeremy.de_clercq@alcatel.be De Clercq Expires August 2003 [Page 14]