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

[Ted Seely <tseely at sprint.net>]

On Sat, 19 Feb 2005, Bandi Sarveshwar-G19441 wrote:

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

sorry for the late reply here, but i think those are some REALLY big
assumptions to be making, and violate every SLAs out there of the SPs
offering L3VPNs today.



>



Ted Seely
Principal Network Design Engineer
Internet Engineering - SprintLink
(W) 703.689.6425
(M) 703.967.3289
AIM - wanpro00
Yahoo IM - tseely01

There are no such things as friends in this industry.