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

[Yakov Rekhter <yakov at juniper.net>]

Thomas,

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

Yes, that does make sense.

Yakov.