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

From: Bandi Sarveshwar-G19441 <[email-masked]>
Date: Sat, 19 Feb 2005 12:33:39 +0530

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

---

From: Yakov Rekhter <[email-masked]>
Date: Sun, 20 Feb 2005 09:46:17 -0800

Sarvesh,

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

Yakov.

---

From: Thomas Morin <[email-masked]>
Date: Mon, 21 Feb 2005 11:31:45 +0100

Hi,

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

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 21 Feb 2005 02:48:28 -0800

Thomas,

> Would that make sense to you ?

Yes, that does make sense.

Yakov.

---

From: Ted Seely <[email-masked]>
Date: Tue, 22 Feb 2005 17:05:44 -0500 (EST)

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

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