[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-ietf-l3vpn-ppvpn-mcast-reqts-00.txt
Thomas,
Thanks for submitting this draft. My comments are inline, below,
prepended with the string "RPB>".
I have omitted sections upon which I had no comment.
Ron
/as individual contributor
1. Introduction
VPN services satisfying requirement defined in [VPN-REQ] are now
being offered by many service providers worldwide. The success of
those VPN services is due to intrinsic characteristics of the
solutions:
- Customers are unaware of the deployed network technology and do
not need to activate specific mechanisms to support traffic being
carried across L3VPN services,
- P-routers in the core do not need to be explicitly aware of the
L3VPN services which allows the P-routers to remain unaware of the
number of VPN customers and so facilitates scalability,
- Operator's configuration actions when adding new customers are
minimized by the dynamic configuration of the VPNs.
- Operator's configuration actions when adding new customers are
minimized by the dynamic configuration of the VPNs.
RPB> The first bullet point describes a reason why BGP/VPN's are
RPB> popular. The second and third bullets point describe architectural
RPB> characteristics of BGP/VPNs. Please consider the following alternative
RPB> text:
RPB> Service Providers are deploying VPN services [VPN-REQ] throughout
RPB> the world. VPN services are popular because customers need not
RPB> be aware of VPN technologies deployed in the provider network.
RPB> They scale well for the following reasons:
RPB>
RPB> - because P-routers need not be aware of VPN service details
RPB> - because the addition of a new VPN member requires only
RPB> limited configuration effort
RPB>
There is also a growing need for support of IP multicast-based
services. Efforts to provide efficient IP multicast routing
protocols and multicast group management have been done in
standardization bodies which has led, in particular, to the
definition of the PIM and IGMP protocols.
However, multicast traffic is not natively supported within existing
PP IP VPN solutions.
RPB>
RPB> /s/PP IP VPN/PPVPN/
RPB>
A simple solution to support multicast-based
services in L3 PPVPNs consists in establishing unicast tunnels across
the core network, and replicating traffic on PEs. Such a technique,
despite the advantage of keeping the core unaware of multicast-
specific issues has obvious drawbacks, which include scalability
issues, operational costs, and bandwidth usage.
RPB>
RPB> I think that the previous paragraph is out of scope for a
RPB> requirements document. It suggests and dismisses a solution.
RPB>
This document complements the generic L3 VPN requirement document
[VPN-REQ], by specifying additional requirements specific to the
deployment of IP multicast-based services within PPVPNs. It
clarifies the needs from both VPN client and provider standpoints and
formulates the problems that should be addressed by technical
solutions with as a key objective to stay solution agnostic.
There is no intent to either specify solution-specific details in
this document or application-specific requirements. Also this
document does NOT aim at expressing multicast-inferred requirements
that are not specific to L3 PPVPNs.
It is expected that solutions that specify procedures and protocol
extensions for multicast in L3 PPVPNs SHOULD satisfy these
requirements.
2. Conventions used in this document
2.1. Terminology
Although the reader is assumed to be familiar with the terminology
defined in [VPN-REQ], [RFC2547bis], [PIM-SM], [PIM-SSM] the following
glossary of terms may be worthwhile.
RPB>
RPB> RFC 2432 might also be an interesting source of terminology
RPB>
3. Problem Statement
3.1. Motivations
More and more L3 VPN customers use IP multicast services within their
private infrastructures. Naturally, they want to extend these
multicast services to remote sites that are connected via a VPN.
For instance, it could be a national TV channel with several
RPB>
RPB> s/it/the customer/
RPB>
geographical locations that wants to broadcast a TV program from a
central point to several regional locations within its VPN.
A solution to support multicast traffic would consist in using point-
to-point tunnels across the provider network and requiring the PE
routers (provider's routers) to replicate traffic. This is obviously
sub-optimal as it places the replication burden on the PE and hence
has very poor scaling characteristics. It may also waste bandwidth
and control plane resources in the provider's network.
RPB>
RPB> This paragraph is repeated from above. Please see comment above.
RPB>
Thus, to provide multicast services for L3 VPN networks in an
efficient manner (that is, with scalable impact on signaling and
protocol state as well as bandwidth usage), in a large scale
environment, new mechanisms are required to enhance existing L3 VPN
solutions for proper support of multicast-based services.
3.3. Scalability vs. Optimality
RPB>
RPB> I don't find the word "optimality" in my dictionary. How about
RPB> "Scaling vs Optimizing Resource Utilization" ?
RPB>
When transporting multicast VPN traffic over a service provider
network, there intrinsically is tension between resource optimization
and minimizing the number of protocol states maintained. Thus, some
trade-off has to be made, and this document will express some
requirements related to this trade-off.
Morin et al. Informational - Expires August 2005 [Page 5]
Internet Draft Requirements for multicast in L3 PPVPNs February 2005
5.1. End user/customer standpoint
5.1.1. Service definition
As for unicast, the multicast service MUST be provider provisioned
and SHALL NOT require the customer's devices (CE) to support some
extra features.
RPB> s/some/any/
5.1.2. CE-PE Multicast routing and management protocols
Consequently to section 3.1, the CEs and PEs SHOULD be able to
operate existing multicast protocols.
RPB> s/be able to operate/employ/
Such protocols SHOULD include : PIM-SM [PIM-SM] (including PIM-SSM
[PIM-SSM], and bidirectional PIM [BIDIR-PIM]), PIM-DM [PIM-DM], and
IGMP (v1, v2 and v3 [IGMPv1] [IGMPv2] [IGMPv3]).
Among those protocols, PIM-SM is considered a MUST.
When IPv6 is supported by a VPN solution, the Multicast Listener
Discovery Protocol (MLD) SHOULD also be supported (v1, v2 [MLD]
[MLDv2]).
5.1.3. Quality of Service (QoS)
First, general considerations about QoS in L3 VPNs as developed in
section 5.5 of [VPN-REQ] are also relevant to this section.
QoS includes various parameters such as delay, jitter, packet loss,
and service availability expressed in percentage of time. These
Morin et al. Informational - Expires August 2005 [Page 6]
Internet Draft Requirements for multicast in L3 PPVPNs February 2005
parameters are already defined for the current unicast provider
provider-provisioned VPN services, are sold by the service provider
to the customers and defined in the SLA (Service Level Agreements).
In some cases, provided SLA may be different between unicast and
multicast, which will need service differentiation mechanisms as
such.
RPB> Please consider the following alternative text:
RPB
RPB> QoS is measured in terms of delay, jitter, packet loss,
RPB> and availability. These metrics are already defined for the current
RPB> unicast PPVPN services, and are included in Service Level Agreements
RPB> (SLA). In some cases, a service provider's unicast SLA may differ
RPB> from its multicast SLA. In those cases.....
The level of availability for the multicast service SHOULD be on par
with what exists for unicast traffic. For instance same traffic
protection mechanisms SHOULD be available for customer multicast
traffic when it is carried over the service provider's network.
RPB>
RPB> Should it be the same as non-VPN multicast? As you state above,
RPB> this might not be different from unicast (either in a VPN or
RPB> not in a VPN?
RPB>
A multicast in VPN solution shall allow to define at least the same
level of quality of service than what exists for unicast.
RPB>
RPB> Same comment as above
RPB>
From this
perspective, the deployment of multicast-based services within an L3
PPVPN environment SHALL benefit from DiffServ [RFC2475] mechanisms
that include multicast traffic identification, classification and
marking capabilities, as well as multicast traffic policing,
scheduling and conditioning capabilities. Such capabilities MUST
therefore be supported by any participating device in the
establishment and the maintenance of the multicast distribution
tunnel within the VPN.
As multicast is often used to deliver high quality services such as
TV broadcast, the solution should have additional features to support
high QoS such as bandwidth reservation and call admission control.
RPB>
RPB> These features don't exist in non-VPN multicast. Therefore, I think
RPB> that the might be out of scope for VPN multicast.
RPB>
Moreover, a multicast VPN solution SHOULD as much as possible ensure
that client multicast traffic packets are neither lost nor
duplicated, even when changes occur in the way a client multicast
data stream is carried over the provider network.
Packet loss issues have also to be considered when a new source
starts to send traffic to a group: any receiver interested in
receiving such traffic SHOULD be serviced accordingly.
5.1.4. SLA parameters measurement
As SLA parameters are part of the service that is sold, they are
often monitored. The monitoring is used for technical reasons by the
service provider and is often sold to the customer for end-to-end
service purposes.
The solution MUST support (SLA) monitoring capabilities, which MAY
possibly rely upon similar techniques (than those used by the unicast
for the same monitoring purposes).
Multicast specific characteristics that may be monitored are, for
instance, multicast statistics per stream, delay and latency time
(time to start receiving a multicast group traffic across the VPN).
A generic discussion of SLAs is provided in [PPVPN-GR].
RPB>
RPB> You might want to visit RFC 2432 for a list of metrics to be
RPB> measured. Please use the terminology of RFC 2432.
RPB>
Morin et al. Informational - Expires August 2005 [Page 7]
Internet Draft Requirements for multicast in L3 PPVPNs February 2005
5.1.5. Security Requirements
Security is a key point for a customer who uses subscribes to a VPN
service. The RFC2547 model [RFC2547bis] offers some guarantees
concerning the security level of data transmission within the VPN.
A multicast VPN solution MUST provide an architecture that can
provide the same level of security both for both the unicast and
multicast traffics.
Moreover, the activation of multicast features SHOULD be possible:
- with a VRF granularity
- with a CE granularity (when multiple CE of a same VPN are connected
to a common VRF)
- with a distinction between multicast reception and emission
- with a multicast group and/or channel granularity
A multicast VPN solution may choose to make the optimality/scal-
ability trade-off stated in section 3.3 by sometimes distributing
multicast traffic of a client group to a larger set of PE routers
that may include PEs which are not part of the VPN. From a security
standpoint, this may be a problem for some VPN customers, thus a
multicast VPN solution using such a scheme MAY offer ways to avoid
this for specific customers (and/or specific customer multicast
streams).
RPB>
RPB> Why would this be a problem so long as the traffic stays inside the
RPB> provider network?
RPB>
5.2.1. Scalability
Some currently standardized and deployed L3VPN solutions have the
major advantage of being scalable in the core regarding the number of
customers and the number of customer routes. For instance, in the
[RFC2547bis] model, a P-router sees a number of MPLS tunnels that is
only linked to the number of PEs and not to the number of customers.
As far as possible, this independence in the core, with respect to
the number of customers and to customer activity, is recommended.
Yet, it is recognized that in our context scalability and resource
usage optimality are competing goals, so this requirement may be
reduced to giving the possibility of bounding the quantity of states
that the service provider needs to maintain in the core for
MDTunnels, with a bound being independent of the multicast activity
of VPN customers.
It is expected that multicast VPN solutions will use some kind of
point point-to-multipoint technology to efficiently carry multicast
VPN traffic, and that such technologies require maintaining state
information, and will use resources in the control plane (memory and
processing, and possibly address space).
Scalability is a key requirement for multicast VPN solutions.
Solutions MUST be designed to scale well with an increase in the
number of any of the following:
- the number of PEs
- the number of customers VPNs (total and per PE)
- the number of PEs and sites in any VPN
- the number of client multicast channels
(groups or source-groups)
>RPB
>RPB I assume that you will add real numbers here
>RPB
Scalability of both performance and operation MUST be considered.
Key considerations SHOULD include:
- the processing resources required by the control plane
(neighborhood or session maintenance messages,
keep-alives, timers, etc.)
- the memory resources needed for the control plane
Morin et al. Informational - Expires August 2005 [Page 11]
Internet Draft Requirements for multicast in L3 PPVPNs February 2005
- the amount of protocol information transmitted to manage
a multicast VPN (e.g. signaling throughput)
- the amount of control plane processing required on PE and P to
add remove a customer site (or a customer from a multicast
session)
- the number of multicast IP addresses used (if IP multicast
in ASM mode is proposed as a multicast distribution tunnel)
- other particular elements inherent to each solution that
impacts scalability (e.g., if a solution uses some distribution
tree inside the core, topology of the tree and number of leaf
nodes may be some of them)
It is expected that the applicability of each solution will be
evaluated with regards to the aforementioned scalability criteria.
These considerations naturally lead us to believe that proposed
solutions SHOULD offer the possibility of sharing such resources
between different multicast streams (between different VPNs, between
different multicast streams of the same or of different VPNs). This
means for instance, if MDTunnels are trees, being able to share an
MDTunnel between several customers.
Those scalability issues are expected to be more significant on P-
routers, but a multicast in VPNs solution should address both P and
PE routers as far as scalability is concerned.
5.2.2. Resource optimization
5.2.5. Infrastructure security
The solution shall provide the same level of security for the service
provider as what currently exist for unicast VPNs.
RPB>
RPB> Should it be the same as non-VPN multicast? As you state above,
RPB> this might not be different from unicast (either in a VPN or
RPB> not in a VPN?
RPB>
For instance,
that means that the intrinsic protection against DOS and DDOS attacks
of the BGP/MPLS VPN solution must be equally supported by the
multicast solution.
Moreover, since multicast traffic and routing are intrinsically
dynamic (receiver-initiated), some mechanism must be proposed so that
the frequency of changes in the way client traffic is carried over
the core is bounded and not tightly coupled to dynamic changes of
multicast traffic in the customer network. For example, multicast
route dampening functions would be one possible mechanism.
Network devices that participate in the deployment and the
maintenance of a given L3 VPN MAY represent a superset of the
participating devices that are also involved in the establishment and
Morin et al. Informational - Expires August 2005 [Page 14]
Internet Draft Requirements for multicast in L3 PPVPNs February 2005
the maintenance of the multicast distribution tunnels. As such the
activation of IP multicast capabilities within a VPN SHOULD be
device-specific, not only to make sure that only the relevant devices
will be multicast-enabled, but also to make sure that multicast
(routing) information will be disseminated to the multicast-enabled
devices only, hence limiting the risk of multicast-inferred DOS
attacks.
Unwanted multicast traffic (e.g. multicast traffic that may be sent
by a source located somewhere in the Internet and for which there is
no interested receiver connected to a given VPN infrastructure) MUST
NOT be propagated within a multicast-enabled VPN.
Last, control mechanisms described in previous section are also to be
considered from this infrastructure security point of view.