Subject: I-D ACTION:draft-ietf-l3vpn-ppvpn-mcast-reqts-00.txt

From: [email-masked]
Date: Mon, 07 Feb 2005 15:43:22 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Layer 3 Virtual Private Networks Working Group of the IETF.

	Title		: Requirements for Multicast in L3 Provider-Provisioned VPNs
	Author(s)	: T. Morin
	Filename	: draft-ietf-l3vpn-ppvpn-mcast-reqts-00.txt
	Pages		: 21
	Date		: 2005-2-4
	
This document presents a set of functional requirements for network 
   solutions that allow the deployment of IP multicast within L3 
   Provider Provisioned virtual private networks (PPVPNs).  It specifies 
   requirements both from the end user and service provider standpoints.  
   It is intended that potential solutions specifying the support of IP 
   multicast within such VPNs will use these requirements as guidelines.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-ppvpn-mcast-reqts-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-l3vpn-ppvpn-mcast-reqts-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-l3vpn-ppvpn-mcast-reqts-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 07 Feb 2005 21:48:15 -0500

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.