Subject: RE: Single vs many solution(s)

From: "Vasile Radoaca" <[email-masked]>
Date: Tue, 6 May 2003 12:37:46 -0400

Neil/Alex
 
               You pointed out clearly mw own concern with Alex' model. What
Alex is proposing assumes
                that most of work was done, and now we are in the process of
simple selecting a single "solution".
 
                Also, his model assumes that once one solution is chosen
than the work is to perfect the solution - but
                what is happen if we need to change something fundamental -
then solution A is still A or would become
                B? And if B was part of initial proposals then what would
become B.
 
                Personal, I believe that talking of only solution at this
point in time is a just misunderstanding of the
                current situation. If we want  a solution to be chosen just
to proof that a VPLS can be implemented than
                I am fine.  
 
          Vasile     

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

Vasile/Alex,

-----Original Message-----
From: Vasile Radoaca [mailto:[email-masked]]
Sent: 06 May 2003 04:21
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, 

NH=> Which 'market'?  Is this (i) the Internet (big 'I') (ii) the
traditional operator (iii) the ISP (iv) the vendor market or some other
market?  Speaking as an operator, we are not driving this market and neither
are our end customers.  Our end customers usually don't care how we
implement our WANs....unless we screw-up through ill-defined solutions.
Their main concerns are cost per bit and reliability/security.  And my
concerns are therefore these plus getting architecturally clean solutions
that drive down my capex/opex.....but that might conflict with the aims of
those wanting shift boxes (who are IMO driving the market) and perhaps some
technology religion/dogma that is creating bad architectures (which at some
point will impact my capex/opex downstream).

  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. 

NH=> Yes indeed. 

  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.  

NH=> I agree.  I have problems with this 'single solution' view *if* it
based on some (G)MPLS/IP unified view of the networking world.  The fact is
cnls, co pkt-sw and co cct-sw modes are *all* needed and they require
different functional solutions.....this is actually at the root of most of
the current day problems/discussions.  Ethernet is something else
again.....it simply does not have the right functional attributes to
scale/work in the WAN environment.  There are some things that are common to
VPNs, but these relate to the setting up/mtce of the *server* layer (lets
say MPLS.....but it could be other) and not the *client* layer distribution
(of routing, if appropriate) that lies above this.  So IPoverMPLS is
different to arbitrary_L2overMPLS is different to EthernetoverMPLS at the
*client* level.....and these are all different (architecturally) to X/IP
cases of same at the *server* level (and some of which we would
deprecate....but that's our call as an operator on what we regard as
sensible or not client/server layer network relationships).

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

NH=> The *server* layer aspects are more simple IMO and these can be unified
(see my related posting).  The difficult aspects relate to client-layer
distribution stuff above this .

 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. 

NH=> I saw no good architectural rationale given for a vote from any
SPs........other than to say we have X so want to keep X for all
applications, without arguments to show why X is still 'right'.  The main
technical arguments have been provided by Eric, Yakov, etc who are not
SPs....but this is largely at a protocol level not the wider arch view.  I
have given some of my views in the past as a traditional operator, looking
to create a sustainable/logical networking world in which cnls, co pkt-sw
and co cct-sw modes can all harmoniously co-exist.

Cheers 
   Vasile 
  
-----Original Message----- 
From: Alex Zinin [mailto:[email-masked] <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: Loa Andersson <[email-masked]>
Date: Tue, 06 May 2003 18:47:48 +0200

Vasile,

should we read this as you in principle want several solutions
for the same problem?

/Loa

Vasile Radoaca wrote:
> Neil/Alex
>  
> You pointed out clearly mw own concern with Alex' model. 
> What Alex is proposing assumes
> that most of work was done, and now we are in the 
> process of simple selecting a single "solution".
> what is happen if we need to change something 
> fundamental - then solution A is still A or would become
> B? And if B was part of initial proposals then what 
> would become B.
>  
> Personal, I believe that talking of only solution at 
> this point in time is a just misunderstanding of the
> current situation. If we want a solution to be chosen 
> just to proof that a VPLS can be implemented than
> I am fine. 
>  
>           Vasile    
>             
> 
>           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, 
> 
>         traditional operator (iii) the ISP (iv) the vendor market or
>         some other market?  Speaking as an operator, we are not driving
>         this market and neither are our end customers.  Our end
>         customers usually don't care how we implement our WANs....unless
>         we screw-up through ill-defined solutions.  Their main concerns
>         are cost per bit and reliability/security.  And my concerns are
>         therefore these plus getting architecturally clean solutions
>         that drive down my capex/opex.....but that might conflict with
>         the aims of those wanting shift boxes (who are IMO driving the
>         market) and perhaps some technology religion/dogma that is
>         creating bad architectures (which at some point will impact my
>         capex/opex downstream).
> 
>          
> 
>           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. 
> 
>         NH=>  Yes indeed. 
> 
>           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.  
> 
>         NH=>  I agree.  I have problems with this 'single solution'
>         view *if* it based on some (G)MPLS/IP unified view of the
>         networking world.  The fact is cnls, co pkt-sw and co cct-sw
>         modes are *all* needed and they require different functional
>         solutions.....this is actually at the root of most of the
>         current day problems/discussions.  Ethernet is something else
>         again.....it simply does not have the right functional
>         attributes to scale/work in the WAN environment.  There are some
>         things that are common to VPNs, but these relate to the setting
>         up/mtce of the *server* layer (lets say MPLS.....but it could be
>         other) and not the *client* layer distribution (of routing, if
>         appropriate) that lies above this.  So IPoverMPLS is different
>         to arbitrary_L2overMPLS is different to EthernetoverMPLS at the
>         *client* level.....and these are all different (architecturally)
>         to X/IP cases of same at the *server* level (and some of which
>         we would deprecate....but that's our call as an operator on what
>         we regard as sensible or not client/server layer network
>         relationships).
> 
>          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). 
> 
>         NH=>  The *server* layer aspects are more simple IMO and these can
>         be unified (see my related posting).  The difficult aspects
>         relate to client-layer distribution stuff above this .
> 
>          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. 
> 
>         NH=>  I saw no good architectural rationale given for a vote from
>         any SPs........other than to say we have X so want to keep X for
>         all applications, without arguments to show why X is still
>         'right'.  The main technical arguments have been provided by
>         Eric, Yakov, etc who are not SPs....but this is largely at a
>         protocol level not the wider arch view.  I have given some of my
>         views in the past as a traditional operator, looking to create a
>         sustainable/logical networking world in which cnls, co pkt-sw
>         From: Alex Zinin [mailto:[email-masked]]
>         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.
> 
>         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.
> 

-- 
Loa Andersson

Mobile          +46 739 81 21 64
Email           [email-masked]

---

From: Alex Zinin <[email-masked]>
Date: Tue, 6 May 2003 11:45:04 -0700

Vasile,

> You pointed out clearly mw own concern with Alex' model. What Alex
> is proposing assumes that most of work was done, and now we are in
> the process of simple selecting a single "solution".

Actually, I don't assume that. In fact, I have stated at least twice,
that we need to approach the problem as a group of engineers from
ground up, looking at what functions we need and how we best implement
them, instead of just picking what we have on the table already.
The reason I used the notion of a 'mechanism <blah>' in my message is
to highlight that some ports of the overall solution are functionally
separateable.

> Also, his model assumes that once one solution is chosen than the
> work is to perfect the solution - but what is happen if we need to
> change something fundamental - then solution A is still A or would
> become B? And if B was part of initial proposals then what would
> become B.

Frankly, you lost me here. You seem to have some specific example
in mind while still operating abstract terms. Can you help me and
give a real example?
 
> Personal, I believe that talking of only solution at this point in
> time is a just misunderstanding of the current situation.

See my other e-mail I just sent to you.

Alex