Subject: Re: draft-mnapierala-mvpn-part-reqt-02

From: Robert Raszuk <[email-masked]>
Date: Fri, 01 Aug 2008 02:06:31 -0700

I agree with Miya & Yuji. The mvpn solution is complex already and
adding any new requirements may only make it more complex hence
resulting in it being practically impossible to deploy.

R.

> In addition to Yuji's point, I'm afraid the rationale for this
> *solution* is not enough clear. Since the entropy level of the MVPN
> solution is already very high :), I think we need to be prudent and
> carefully examine pros and cons of adopting this proposal, before
> making this a WG document,
> 
> Miya
> --------------------------------------------------------------------------------
> From: [email-masked] <mailto:[email-masked]>  On Behalf of NAPIERALA, MARIA H, ATTLABS
> Sent: 2008/07/23 (Wed) 21:26
> To: Yuji KAMITE; [email-masked] <mailto:[email-masked]> 
> Subject: RE: draft-mnapierala-mvpn-part-reqt-02
> 
> Yuji,
>> To me the current text (Section 1 and 2) does not yet explain
>> this point very well.  So I'd like to see the motivation/background
>> and justification more.
> 
> Sure. This can be done.
> 
> Maria
> -----Original Message-----
> From: [email-masked] <mailto:[email-masked]>  [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf
> Of Yuji KAMITE
> Sent: Wednesday, July 23, 2008 3:29 AM
> To: [email-masked] <mailto:[email-masked]> 
> Subject: RE: draft-mnapierala-mvpn-part-reqt-02
> 
> Regarding the content,  it's not clear what the
> "partitioning"  exactly means (definition in VPN context)
> and why it is needed.  Does this offer new benefit to high reliability
> or new service to the customer?
> 
> To me the current text (Section 1 and 2) does not yet explain
> this point very well.  So I'd like to see the motivation/background
> and justification more.
> 
> Yuji
> 
>> -----Original Message-----
>> From: [email-masked] <mailto:[email-masked]>  [mailto:[email-masked] <mailto:[email-masked]> ]
>> On Behalf Of Ron Bonica
>> Sent: Friday, June 27, 2008 3:20 AM
>> To: [email-masked] <mailto:[email-masked]> 
>> Subject: draft-mnapierala-mvpn-part-reqt-02
>>
>>
>> Folks,
>>
>> Maria Napierala has asked the WG to adopt
>> draft-mnapierala-mvpn-part-reqt-02 as a WG item. If you have
>> any opinion
>>   regarding whether it should be adopted, please post a
>> message to the list.
>>
>>                                       Ron
>>
>>
>

---

From: "NAPIERALA, MARIA H, ATTLABS" <[email-masked]>
Date: Fri, 1 Aug 2008 05:30:24 -0400

These requirements do not make the mvpn solution more complex. This is a
misconception. As far as Bidir is concerned, it is required because VPN
customers are using it and supporting it will add (if not decide) about
the success of this technology. In addition, Bidir is very scalable
because it only generates one multicast route per multicast group. So,
it helps to scale MVPN/PE. 

(BTW - Yuji did not say that new requirements will make the MVPN
solution more complex if you read his e-mail carefully. He asked for
more explanation).

Maria
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Robert Raszuk
Sent: Friday, August 01, 2008 5:07 AM
To: [email-masked]
Subject: Re: draft-mnapierala-mvpn-part-reqt-02

R.

> making this a WG document,
------------------------------------------------------------------------
--------
> From: [email-masked] <mailto:[email-masked]>
[mailto:[email-masked] <mailto:[email-masked]> ] On
Behalf
>> From: [email-masked] <mailto:[email-masked]>
[mailto:[email-masked] <mailto:[email-masked]> ]

---

From: "Miya Kohno" <[email-masked]>
Date: Fri, 1 Aug 2008 18:22:58 +0800

I did neither say the requirements make the MVPN more complex ! 
 
"Simple/Complex" is a subjective word in many cases, so we'd avoid it as far as possible. (e.g. Bidir could be simple and scalable from one perspective, but it'd be highly questionable from ASIC point of view, etc.)
 
But I think it appears certain that the MVPN solution today is already very "diverse". (I guess this is what Robert tried to say as well.). And only my point was we'd need more prudent consideration and evaluation.
 
Miya
________________________________

From: [email-masked] 代理 NAPIERALA, MARIA H, ATTLABS
Sent: 2008/08/01 (金) 17:30
To: Robert Raszuk; [email-masked]
Subject: RE: draft-mnapierala-mvpn-part-reqt-02

Maria
-----Original Message-----

R.

---

From: "Yuji KAMITE" <[email-masked]>
Date: Fri, 01 Aug 2008 20:00:36 +0900

>If you have interest in this work, could you please reply
>to the following question with a simple "yes" or "no"?
>
>Would you like to accept draft-mnapierala-mvpn-part-reqt
>as an L3VPN WG document?

At this moment I say "no" because the current document does 
describe neither problem statement nor user benefit explicitly.
Maria needs to state those points (at the beginning sections maybe) to
organize the document, and share the consensus on the requirement
among other SPs.  The position of the document should be clearly
stated as an complementary requirement to RFC4834.

However, regarding her basic idea, I think it can be "yes" on the
condition that those points above be clarified in the document.
I believe nobody cannot deny investigating new requirements if our
end customer and SP really wants them.   Actual our daily operation
tends to raise new requirements which we have not noticed so far.  

Please note that my point above is purely about the current
content in draft-mnapierala-mvpn-part-reqt itself.

The discussion about how to progress the existing
solution work items, would be another matter here.

Regards,
Yuji

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of NAPIERALA, MARIA H, ATTLABS
> Sent: Friday, August 01, 2008 6:30 PM
> To: [email-masked]; [email-masked]
> These requirements do not make the mvpn solution more 
> complex. This is a misconception. As far as Bidir is 
> concerned, it is required because VPN customers are using it 
> and supporting it will add (if not decide) about the success 
> of this technology. In addition, Bidir is very scalable 
> because it only generates one multicast route per multicast 
> group. So, it helps to scale MVPN/PE. 
> 
> (BTW - Yuji did not say that new requirements will make the 
> MVPN solution more complex if you read his e-mail carefully. 
> He asked for more explanation).
> 
> Maria
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Robert Raszuk
> I agree with Miya & Yuji. The mvpn solution is complex 
> already and adding any new requirements may only make it more 
> complex hence resulting in it being practically impossible to deploy.
> 
> R.
> 
> >> To me the current text (Section 1 and 2) does not yet explain this 
> >> point very well.  So I'd like to see the motivation/background and 
> >> justification more.
> > 
> > Sure. This can be done.
> > 
> > Maria
> [mailto:[email-masked] 
> <mailto:[email-masked]> ] On Behalf
> > Of Yuji KAMITE
> > Regarding the content,  it's not clear what the "partitioning"  
> > exactly means (definition in VPN context) and why it is 
> needed.  Does 
> > this offer new benefit to high reliability or new service to the 
> > customer?
> > 
> > To me the current text (Section 1 and 2) does not yet explain this 
> > point very well.  So I'd like to see the motivation/background and 
> > justification more.
> > 
> > Yuji
> > 
> >> draft-mnapierala-mvpn-part-reqt-02 as a WG item. If you have any 
> >> opinion
> >>   regarding whether it should be adopted, please post a message to 
> >> the list.
> >>
> >>                                       Ron
> >>
> >>
> > 
>

---

From: IJsbrand Wijnands <[email-masked]>
Date: Fri, 1 Aug 2008 13:17:15 +0200

Robert,

> resulting in it being practically impossible to deploy.

That depends on what solution 'profile' you have in mind.

The 'PIM over MS-PMSI' profile in draft-rosen-l3vpn-mvpn-profiles-01  
(section 4) addresses all the requires that Maria raised, without  
increasing the complexity.

Thx,

Ice.

>> On Behalf

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 1 Aug 2008 09:00:32 -0400

Do you have reasons to back up why those requirements do make it more  
complex or are you just speculating?

	--Tom

>> From: [email-masked] <mailto:[email-masked]>  [mailto:[email-masked]