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

[Thomas Morin <thomas.morin at rd.francetelecom.com>]

Hi,


Yakov Rekhter :
>Sarvesh,
>
>> <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 ove r the others. Or the other way around, the
>> SP may want to give preferential tre atment to customer traffic
>> depending on what they are paying for.
>
>I certainly agree with you. The QoS features mentioned above
>are available for the unicast 2547 VPN service, and should
>be available for the multicast 2547 VPN service as well.


I think Ronald was referring to the fact that the initial paragraph was
in the *customer side* requirements section. And I admit the paragraph
may not make a consensus, since with the multicast protocols we
require/suggest at the CE-PE level, there is no existing mechanism for
bandwidth reservation or CaC. In that sense, we may change this
paragraph. 
( but we may also say that if we require support of the Carriers's
Carrier model  - not yet developed in last revision - then things may be
different...)

What you both (Yakov, Sarvesh) just suggested is a bit different, and is
in my view closer to and ISP-side requirement, something like "what kind
of SLAs can I sell ? how differentiated ? and how can I
enforce/guarantee it ?".  In that sense, we could state in the ISP
requirements section the need for mechanisms able to produce different
QoS and/or bandwidth guarantees for different customers. 

Would that make sense to you ?

-Thomas

--
== Thomas MORIN - France Telecom R&D CORE-CPN
== Tel.: +33(0) 2 96 05 37 34 - www.francetelecom.com/rd
--