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

[Bandi Sarveshwar-G19441 <sarvesh at motorola.com>]

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

Yeah you are right when you say these feature do not exist in non-VPN multicast. But in the problem that we are addressing, the cusomters would end up buying Multicast VPN service from the providers and I think they would like to know the performance characteristics of the service being provided. While customers can control the performance of multicast data transmission in their network, I guess it would be unacceptable if they cant determine what the behaviour would be like when data crosses from PE to PE.

Moreover since the SP is serving different VPNs, if there are no QoS guarantees, the possibility exists that SP can start favouring customers of one VPN over the others. Or the other way around, the SP may want to give preferential treatment to customer traffic depending on what they are paying for.