Subject: RE: Single vs many solution(s)

From: "Ron Haberman" <[email-masked]>
Date: Tue, 6 May 2003 15:55:13 -0400

Vasile,

I don't think that it either one is "wrong" as someone that works for a
SP I would like to get simple signaling. I can live without
auto-discovery because I have access to other tools that provide the
same end result. I will however use auto-discovery if it was done in a
way that makes sense to me, and that precludes BGP as it is a push
protocol (send all information everywhere) as oppose to any directory
service which is using a pull protocol (each device requests information
related to it self). As to the "current IP VPN market", I was running
Martini long before 2547. If I had to run VPLS in a similar fashion to
either one I would choose Martini and not 2547. As to the "lack" of
vendors to give SP everything they want now, I don't think that is a
problem, I will (and I am sure others do) select the vendors they
believe are going at the right direction. If a vendor doesn't have
auto-discovery now, but I believe will at some point have an
auto-discovery mechanism that makes sense to me, I will choose that
vendor.

Masergy Communications is an example for a company that actually IS
running all three VPNs. We are running L2 point to point for about two
years, 2547 for more than a year and are actually currently running
(currently as in not planning to, thinking about it, evaluating) VPLS
service for about a month and a half in our production network. 

Although I think the argument of 'run type X of VPLS because you also
run type Y of some other VPN' is  flawed I will participate and tell you
that what I have implemented in Masergy's network is:
*) Edge device 1: Used for L3: Internet access, 2547. The device is
running IGP, BGP, RSVP.
*) Edge device 2: Used for L2: Point-to-point services, VPLS service.
The device is running IGP, RSVP, TLDP. IMHO It is much easier to manage
L2VPN devices when they don't need to run BGP at all (less
configuration) not to mention that customers are much more comfortable
when they hear that the devices running their L2 VPNs are not connected
to the Internet (read BGP).

Thanks,
Ron.

-----Original Message-----
From: Vasile Radoaca [mailto:[email-masked]] 
Sent: Tuesday, May 06, 2003 11:11 AM
To: [email-masked]'; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: Single vs many solution(s)

         Richard,

             You rise an interesting aspect of the problem - It seems
that is desire or  there are requirements from the
              SPs to simplify the signaling, auto-discovery and to
overlap the VPLS deployment with the current IP VPN market.
Unfortunately, such requirements were not captured at the right time in
the PPVN Requirement document, which was finalized only little bit ago. 
             It is wrong that they are looking to have such elegance or
simplicity or is wrong that we don't have the right tools, or
imagination to solve such problems?

           Vasile
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, May 06, 2003 10:27 AM
To: [email-masked]; Radoaca, Vasile [BL60:X624:EXCH];
[email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: Single vs many solution(s)

Himanshu, 

I believe that there can exist multiple solutions for different sets
of problems. However, one must not confuse the solution with
signaling. We oughta not have two signaling mechanisms for 
two solutions to the same problem.

[RS: I agree that there should only be one 'functional specification'.
However, I don't think we can rule out the possibility of having to use
more than one protocol for each function until the functional
specifications have been developed.] 

A while back, it was determined that PW setup signaling is not
the charter of PPVPN but of PWE3. Lately, we have been 
discussing again whether BGP based signaling is better than LDP
based signaling. We have got to get past this issue once and for
all. My personal experience (having implemented BGP based 
signaling for L2VPN) is that my previous company could not find any
customer 
demand for BGP-based solution (we did not look into Italy though :-) 
However, there was greater interest in LDP based solution and
public forums to test interoperability with.

[RS: Carrying out a quick count of the individuals that have expressed
support on this mailing list for the two opposing drafts (K.Kompella vs.
V.Kompella/Lasserre), based on whether they work for an SP or a vendor
the results are (roughly):

Draft     Vendor Support    SP Support
BGP              4                      19
LDP               7                       3

These results would suggest that customers (i.e. SPs) prefer the BGP
approach. I am not saying that I agree, far from it, but I don't think
that we should rule out protocols at this stage, especially in the
inter-AS case. Instead we should be focussing on getting the functional
specifications correct.]

I think we have learned enough lessons from CR-LDP vs RSVP-TE
debacle. Lets not repeat it for L2VPN.

...Richard 

 -----Original Message-----
From: Vasile Radoaca [mailto:[email-masked]]
Sent: Monday, May 05, 2003 11:21 PM
To: 'Alex Zinin'; [email-masked]
Cc: Yakov Rekhter
Subject: RE: Single vs many solution(s)

Alex, 
  I think the ideal goal is to have only one solution, but such ideal
usual can be achieved if we are working in a pure theoretical
environment, without market considerations. In reality the market is
driving in most of the cases, and some assumptions made two years ago
are not any more valid - there are categories of SPs that pretty much
have disappeared from the map.
  You stated very clear that a problem space needs to have a single
solution. I fully agree with you as a goal, but ut the issue that we
face right now is that the problem space is not well concluded and well
understood just purely from technical considerations. 
 The L2 VPLS is a complex space with multiple dimensions, and the
vendors - in the last two years -  have worked from different angles,
optimizing one or more dimension(s) of the problem space (probable the
downturn in the market it self, was part of the problem). Without to
contradict each other, most of the solutions are closed in a specific
dimension, based on some objective/subjective parameters or experience
and some criteria of optimization. Moving in only one dimension doesn't
scale it self.

 The fact we do have more than one solution, I think is a good thing,
and doesn't contradict that we can't move toward one solution, if we are
driving diligently, and willing to make compromises. Taken such research
value in consideration, would be a positive sign that IETF is looking to
create a solution that would be valid for a while. Reading the mailing
list, I observed the same wise advise from most of the SPs, and this
reflect not a "problem" but a reality.

Cheers 
   Vasile 
  
-----Original Message----- 
From: Alex Zinin [mailto:[email-masked]] 
Sent: Monday, May 05, 2003 5:27 PM 
To: [email-masked] 
Cc: Yakov Rekhter 
Subject: Single vs many solution(s) 

Yakov, 
[I took the liberty to change the subject line] 
>> I believe the goal for the WG should be to work out 
>> a single solution. 
> That is certainly not in the charter. In fact the goal 
> you stated above directly contradicts what is in the charter: 
>    Multiple approaches are being developed as each approach 
>    has particular characteristics and differing scope of 
> applicability. 
Thanks for pointing out a possible contradiction. I don't think it
exists. 
My opinion (and I think it would be safe for me to say it is consistent
with that of the IESG) is that as long as different solutions are
solving different problems (or, as the text of the charter says, have
different scopes of applicability), it is fine to have more than one
solution. However, for a single problem, we only need a single STD'ized
solution.
> And if you believe that for VPLS the goal should be a single solution,

> then why wouldn't you insist to have the same goal for L3 VPNs ? 
you forgot to add "and if you wouldn't insist on a single solution for
L3 VPNs, then why do you insist on this for L2 VPNs" ;-)
The reason is I don't want to restart the L3 VPN work in the IETF and/or
revisit the decisions that have been made in the past, while I still see
a reasonable opportunity to steer the L2 VPN work.
> Also, if you insist on a single solution, wouldn't that 
> imply a single auto-discovery mechanism for VPLS ? 
This would definitely be my preference. 
Alex

---

From: Pedro Roque Marques <[email-masked]>
Date: Tue, 6 May 2003 15:21:50 -0700 (PDT)

Ron Haberman writes:

> running all three VPNs. We are running L2 point to point for about
> two years, 2547 for more than a year and are actually currently
> running (currently as in not planning to, thinking about it,
> evaluating) VPLS service for about a month and a half in our
> production network.

Ron,
How would you rate the contribution of the ppvpn WG to the services
that you are providing ? Are those solutions based on technology
discussed in this WG ?

The proposed reoganization is based on:
   "numerous concerns that the IESG members received from the WG
    participants about limited and slow progress within the WG despite the
    efforts of the WG chairs and its members."

I assume that those concerns about "limited and slow progress" have
been voiced mostly in private. To a more distant observer like myself
it isn't easy to understand what those are and what constitutes a
messure of "success" or "failure" of the WG efforts.

I'm hoping that we can learn from whatever concerns exist with the
current group in order for those issues not to reoccur with the new
proposed structure.

I would hope that people like yourself which are activly engaged in
deploying the technology can point out the things this WG did
correctly (if any) or wrongly.

regards,
  Pedro.

---

From: Rahul Aggarwal <[email-masked]>
Date: Tue, 6 May 2003 16:07:40 -0700 (PDT)

Hi Ron and Pedro,

[Took the liberty of changing the subject line]

Your mails bring out a very key question. The PPVPN WG has been in the
business of developing L3 and L2 VPN technology that providers can deploy
to offer these services. 

Do providers feel they are unable to deploy/offer L3 VPN service because
of limitations with the WG ?

Do providers feel they are unable to deploy/offer L2 VPN service because
of limitations with the WG ?

If the answer is yes, what are these limitations ? From a distance it
seems that the business/economic case is more of a reason, if any, for any
seemingly slow deployment.

Or do vendors feel they are unable to develop this technology because of
limitations with this WG ? 
   My answer to this is no.

Regards,
rahul