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

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

Yup. That adds more clarity I guess.

- Sarvesh


-----Original Message-----
From: Thomas Morin [mailto:thomas.morin at rd.francetelecom.com] 
Sent: Monday, February 21, 2005 4:02 PM
To: Yakov Rekhter
Cc: Bandi Sarveshwar-G19441; 'Ronald Bonica'; l3vpn at ietf.org
Subject: Re: I-D ACTION:draft-ietf-l3vpn-ppvpn-mcast-reqts-00.txt


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