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

From: Bandi Sarveshwar-G19441 <[email-masked]>
Date: Sat, 19 Feb 2005 14:00:22 +0530

Len and others,
In RFC2547bis, sending traffic of one VPN to another is achieved by policy configuration (RT and RD). The export and import policies pretty much decide which destinations in which VPNs are accessible to others. Multicast routing protocols like PIM (all variants) depend on the unicast routing database to propagate multicast control messages (Joins/Prunes). In that sense the policies for Multicast routing protocols operations should match with those unicast VPN policies (as in RFC2547bis).

would it be useful to add text in the requirements document in this regards? Or whatever I mentioned above is taken for granted?

Sarvesh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Len Nieman
Sent: Thursday, February 10, 2005 7:33 PM
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-l3vpn-ppvpn-mcast-reqts-00.txt

In addition to Ron's comments, I would suggest changing the fourth paragraph under '5.1.7. Extranet':

"For instance, an enterprise using a multicast-enabled VPN should be able to receive multicast streams sent by a source in another VPN, and should also be able to be a source for a multicast stream towards another VPN."

To the stronger and more direct form:

'For instance, an enterprise using a multicast-enabled VPN should have the ability to receive a multicast stream from, or originate a multicast stream towards, another VPN.'

Len Nieman
(Bellsouth's my ISP,
not my employer)

---

From: Bandi Sarveshwar-G19441 <[email-masked]>
Date: Mon, 21 Feb 2005 16:24:24 +0530

Yup. That adds more clarity I guess.

- Sarvesh

-----Original Message-----
From: Thomas Morin [mailto:[email-masked]] 
Sent: Monday, February 21, 2005 4:02 PM
To: Yakov Rekhter
Cc: Bandi Sarveshwar-G19441; 'Ronald Bonica'; [email-masked]
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
--