Subject: RE: Single vs many solution(s)

From: "Himanshu Shah" <[email-masked]>
Date: Tue, 6 May 2003 09:19:11 -0400

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.
 
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. 
 
I think we have learned enough lessons from CR-LDP vs RSVP-TE
debacle. Lets not repeat it for L2VPN.
 
/himanshu
Wavesmith Networks

 
 -----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: "Vasile Radoaca" <[email-masked]>
Date: Tue, 6 May 2003 10:05:24 -0400

Himanshu, Alex
 
           BGP signaling is a different story - I do belive that underline
principle is to evaluate
           if we can decouple signaling from the vertical VPLS solution.  We
do the same with
           Auto-discovery. Eric did a good analysis of the problem, but I
don't believe that was very forceful
           in rejecting BGP signaling for Any to ANy model. I am looking to
have another stage of discussion
           without rejecting the current proposals.
 
           The problem is that we do not exactly how the VPLS as  service
will evolve in the future - also the SPs
           they do not exactly how this service would be use. It would
complement the IP VPN, it would be an 
           alternative of the IP VPN, or it would be a commodity [like
LAN/VLAN are today in the Enterprise space].
 
           Your e-mail also reflects different  vendors experience, which is
worth by it self to be evaluated.
 
         CHeers
              Vasile

-----Original Message-----
From: Himanshu Shah [mailto:[email-masked]] 
Sent: Tuesday, May 06, 2003 9:19 AM
To: Radoaca, Vasile [BL60:X624:EXCH]; Alex Zinin; [email-masked]
Cc: Yakov Rekhter
Subject: RE: Single vs many solution(s)

 
 
/himanshu
Wavesmith Networks

 
 -----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] <mailto:[email-masked]> ] 
Sent: Monday, May 05, 2003 5:27 PM 
To: [email-masked] 
Cc: Yakov Rekhter 
Subject: Single vs many solution(s) 

Yakov, 

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.

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

Alex

---

From: "Vasile Radoaca" <[email-masked]>
Date: Tue, 6 May 2003 11:10:54 -0400

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, 

[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.] 

[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.]

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

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, 

Alex

---

From: [email-masked]
Date: Tue, 6 May 2003 16:15:52 +0100

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, 

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. 

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.

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, 

Alex

---

From: "Hector Avalos" <[email-masked]>
Date: Tue, 6 May 2003 19:07:32 +0200

Vach,
 
-----Original Message-----
From: Vach Kompella [mailto:[email-masked]] 
Sent: mardi 6 mai 2003 18:14
To: [email-masked]; [email-masked]; Vasile Radoaca;

Richard,
 
Were you at the IETF in San Francisco?  Did you count the
vendor/provider support there?  There is an incorrect notion that just
because a number of "individuals who work for providers" have supported
the BGP draft, that there is provider support for it.
 
To continue this further: how would you evaluate the "support" an
individual who works for a vendor that does not have a box that even
remotely can perform L2VPN functions?   
 
 How would you evaluate the "support" of an individual who works for a
provider that is not remotely connected to the department that would
either make the decision to provide L2VPNs or implement or support
L2VPNs? 
[Hector:  from the 19 SP supporting the kompella approach you have
Telefonica, Equant, FT, Telia and Lambdanet.....
and the individuals who sent the e-mails are connected to the decission
to implement or support L2VPNs in their companies. 
]

Individuals at the IETF cast their support as individuals.  If you want
to qualify it as vendor or provider support, then please take the extra
step of figuring out if they really speak for the company.  Thanks.
 
-Vach

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, May 06, 2003 7:27 AM
To: [email-masked]; Vasile Radoaca; [email-masked];
[email-masked]
Cc: [email-masked]

Himanshu, 

[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.] 
 
signaling for L2VPN) is that my previous company could not find any
customer 

[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):

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

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

>    has particular characteristics and differing scope of 

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.

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

Alex

---

From: "Vasile Radoaca" <[email-masked]>
Date: Tue, 6 May 2003 13:15:01 -0400

Loa,

 Did we identify clearly only one problem? 
 
 I wish to have only one final solution - but what Alex doesn't show us how
we can
 move toward such solution. What are the intermediate points to get to the
final
 destination - and here I think we need to be little bit more inventive.
 Can we use intermediate "solutions/mechanisms" that are not fundamental in
contradiction to
 converge toward a single solution?

Cheers
  Vasile

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]] 
Sent: Tuesday, May 06, 2003 12:48 PM
To: Radoaca, Vasile [BL60:X624:EXCH]
Cc: [email-masked]'; [email-masked]; [email-masked];
[email-masked]
Subject: Re: Single vs many solution(s)

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".
> 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    
>             
> 
>     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]
>           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
>         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
>         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: [email-masked]
Date: Tue, 6 May 2003 17:11:59 +0100

Hi Alex.....A timely mail/comment IMO.  My view is the protocol war (ie 'my
protocol is better than yours') is completely missing the point, and is
simply a symptom of a far deeper architectural problem.  We have to
understand this and get this right first.....because IMO it is this lack of
architectural regonition/understanding of the real problem (whether
accidental or malicious) that is causing so many kludges to appear.

The basic problem IETF face is that it is trying to serve 2 completely
different masters:  There is the public Internet (big 'I') and there is the
commercial exploitation of layer networks.....where the cnls mode (with IP
as the dominant cnls technology) is but 1 mode here....witness GMPLS and
MPLS: not at all clear to me why these are that relevant to the Internet,
and where the former dabbles in the technologies that belong to the (L1) co
cct-sw mode, whilst the latter does its best to pretend it's not dealing
with a co pkt-sw mode.

This is where the architectural rot starts.  As I have said many times
before on various IETF mail lists (but will repeat because its so important
to recognise and is really at the heart of this discussion IMO), there are 3
fundamental network modes:
-	cnls
-	co pkt-sw
-	co cct-sw
*All* technologies map to one of these modes.  Operators need *all* 3 modes
to optimally deliver all the different types of services required by
customers.  Each mode has different functional behaviours that are
determined by the technical/commercial requirements it has to satisfy.  It
makes no sense to try and force functional convergence across *all* the
modes, but it does make lots of sense to functionally converge different
technologies that belong to the *same* mode....this mitigates against the
'stovepipe' problem (ie technology=service) and gateway problem of
protocol/function conversion in both the data and control planes.

So what I am looking for as an operator is to be able to select a common
core technology for *each* of the above modes.  cnls is easy, its IP.  co
cct-sw is easy, today it's SDH and tomorrow it will be OTNs (though I don't
expect SDH to go away in the forseeable future).  I would also like MPLS to
become the common co pkt-sw core (and I would like to do edge conversion to
grandfather other co pkt-sw technologies , eg FR and ATM).....but this can
only happen if MPLS is correctly functionally specified.
Note - One can have client/server relationships between the 3 different
modes (though only some relationships make sense in our view), but one
cannot have peer-interworking (ie protocol-conversion) between the modes.

If one accepts this then several consequential 'networking truths' must also
be accepted.  For example, there is no need for the functional components of
each mode to be the same....in fact to do would be far from optimal.
Further, there is no need for the functional components to come as 1
amorphous set with no choices per functional component.  What I mean by this
is as follows:  As an operator I have a requirement to be able to choose
addressing, routing, signalling (for the 2 co modes), OAM, etc functional
components *independently* (using best-of-breed selection criteria) both per
mode and within each mode.   If anyone tells me that I can apply the same
common networking solution to an IP network as I can to an optical network
then I would regard such an individual as barking mad.....and yet that is
the what all the (G)MPLS stuff is supposed to be about.

Now let's specifically look at the VPN problem which triggered the 'protocol
war' discussions and Alex's original mail in the context of the above:

Let's consider the VPN problem we are trying to address using MPLS as the
common co pkt-sw core server layer technology and see if we can identify
what is common and what is not common.  Let's consider 3 types of VPN:
-	those with IP as the client layer type, eg rfc2547 type
-	those with ethernet as the client type, eg VPLS/VLANs
-	those with no specific client type....so this would be the MPLS
equivalent of FR or ATM today.....and of course this fits the bill when one
wants to offer an MPLS transit service.

We can split the problem up as follows:

1	We must have some means of identifying MPLS data-plane access points
that is independent of the client networks that are
supported.....specifically both client and server layer networks require
their own addressing (even if same format, they come from disjoint spaces).
This does happen today in MPLS, but seems to occur subconciously(?) based on
whatever signalling protocol is used to define the 'tunnel IDs'....so we
don't have a consistent/single addressing scheme for MPLS access points.
Note also that these are not *IP* v4 addresses, but some new addresses that
have been created from combining a v4 address-type with some 'tunnel IDs',
ie these addresses don't belong in the 'IP layer network space' at all but
only in the 'MPLS network space', and also *specific* to the signalling
protocol used to define them.  However, speaking as an operator I would like
to see a consistent/single way to identify MPLS data-plane access points
emerge (irrespective of which signalling protocol is used, including
'none')....for exmaple, we could define these based on the v6 format (but it
is not the *IP* v6 space for the reasons noted previously).

2	The next issue is that we need to associate a given set of MPLS
access point addresses with the site locations of VPNs.  So we need a VPN-ID
that is unique and common to all the MPLS access point addresses which are
going to be used to create the VPN server layer topology.  We use this
information to perform *discovery* (in the MPLS server layer) using protocol
X say.

3	Next, having identified the access points of a given VPN's MPLS
server layer, we need to set-up, via *signalling* using protocol Y say, the
LSPs that create the VPN topology.

{Aside.  Note that the above is *common* to all types of MPLS-based VPN.
Now we can consider the specific VPN types themselves, which are effectively
differentiated by the client they support.}

4	RFC2547 VPNs.  The client is IPv4.  This has its own address
challenges.  So we add an 8 octet RD to the v4 addresses within the VPNs to
make them unique in their own layer.  It seems natural to use BGP4 to
distribute the client layer addressing information because this is a routing
protocol designed for this type of client.....but note this is strictly a
client layer address distribution issue.  The fact we are using the
provider's BPG4 to do this stems from the fact that this is what BGP4 was
designed for, ie IP layer address distribution.  We also ask BGP to
distribute some labels for use by the MPLS data-plane that are bound with
specific client layer address prefixs.  This again arguably makes sense
because the client is IP.

5	ethernet/VLANs.  The client is ethernet with or without VLAN
identifiers.  Client layer address distribution is done directly in the
client's data-plane based on broadcasting/learning/aging.   There is no
*forced* need for an operator to own this problem.....all the
ethernet/VLAN/bridging/etc functionality can be done in the client layer and
all the operator doing is providing a simple MPLS VPN (like ATM/FR today).
If one wants to go further than this and take on the client layer address
distribution role in the core network, then the problems of
scaling/fault-managing/resilience/etc that have been discussed have to be
addressed.  These are not trivial issues because the ethernet client layer
was never designed with WAN deployment in mind.  Its not at all obvious
*why* an operator would wish to take these functions on board at the current
time.

6	Simple MPLS VPNs.  The client is irrelevant (or at least ought to
me....cue entrance of LDP/ECMP/MPLS_PID kludge however).  But what is wrong
with providing a simple MPLS managed BW service?  Might this not be
attractive to certain customers who wish to own/control their own client
layer network(s) above this.....which is also a simple MPLS transit service
if you think about it.  Note this is also what the previous ethernet/VLAN
service defaults to when the operator does not take on the role of client
layer 'address' distribution.

So if I look at the base/common required functional behaviour we want from
L2 VPNs it seems to me we need:
-	a set of globally unique addressed access points
-	a means to associate a set of these addresses with a VPN ID
-	a means to distribute those addresses amongst members of a VPN
-	a means to automatically set-up trails (and thereby the topology)
between the access points that belong to the same VPN
-	plus a means to authenticate ad hoc 'joins' to a VPN

These are the common MPLS *server* layer issues across VPN types.  The key
differences occur in the handling of the specific *client* layer IMO, and I
think we should separate these 2 aspects.  Its not clear to me that anyone
is actually thinking along these lines as yet, but I see this as the most
obvious logical split.

regards, Neil

---

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

Richard,

There is a flaw in the way you counted the votes, you didn't count my
vote for the LDP solution (I work for a SP). The reason you didn't count
it that you couldn't, I didn't send it until now. 

Like most people (both SP and vendors) that support the LDP solution, I
was following the instructions from the chairs which were different for
the two drafts. While Lasserre-VKompella was already voted on in SF, the
chairs solicited mainly negative input as in "tell me why this shouldn't
move forward or it will" while authors of Kompella-VPLS were requested
to get support in order to move forward. Since I support the first and
not the later I just remained silent.

On that topic I would like to ask the chairs what is the current status
of moving drafts to WG documents. According to the last email about that
(about 4 weeks ago?) the WG had only a week to respond before the
document moves forward. Any news about it?

Thanks,
Ron.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, May 06, 2003 10:27 AM
To: [email-masked]; Vasile Radoaca; [email-masked];
[email-masked]
Cc: [email-masked]

Himanshu, 

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

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,

---

From: Mark Seery <[email-masked]>
Date: Tue, 6 May 2003 12:32:55 -0700 (PDT)

Neil,

>> NH: Operators need *all* 3 mode....<<

Is there any publicly available information explaining
the rationale for this statement? Not disputing it,
just like to understand the details of the logic.

>> NH: Let's consider the VPN problem we are trying to
address using MPLS as the common co pkt-sw core server
layer technology and see if we can identify what is
common and what is not common. <<

When you say "we" I assume you mean BT. It is not
clear to me that is a generally accepted truth.
Forgetting about the IP option for a second, it would
seem that the very presence of PWE suggests another
server layer (as I think you have essentially stated).

But more importantly, it is not clear that there is
consenus that LDP provides a co pkt-sw capability, in
fact I've seen many arguments to the contrary,
certainly within the MPLS WG; and I know at some level
you are yourself concerned that it does not, so seems
some consensus on this issue is required if we go down
the road of defining functional requirements.

>> NH: 5. ethernet/VLANs.  The client is ethernet with
or without VLAN identifiers.  Client layer address
distribution is done directly in the client's
data-plane based on broadcasting/learning/aging. There
is no *forced* need for an operator to own this
problem.....all the ethernet/VLAN/bridging/etc
functionality can be done in the client layer and all
the operator doing is providing a simple MPLS VPN
(like ATM/FR today). <<

So I think I have argued one way or another that I am
concerned about putting too much Ethernet client stuff
in the network so keep that in mind as I make the
following comments.

The problem with today's client/server model is that
the server layer is a point-to-point trail, that means
if the operator wants to offer a switched service
based on the client payload, then the PDU has to be
popped out of the trail and switched by a different
piece of equipment, i.e. there is a difference between
a switched transport infrastructure and a switched
service. Seems to me that the unspoken aim of VPLS is
to avoid this. Now should we intermingle the client
layer switching/briding solution together with the
server layer solution - this is where I see potential
for inter-standards body conflict and architectural
conerns.

Additionally, with point-to-point trails a mesh is
required. What VPLS is trying to do is move that mesh
from the subscriber/access to inside the edge/core
network. This is one incremental step in the right
direction; and maybe an important first step to get to
market etc. Ultimately though, the option of having a
true multipoint server layer might be an interesting
option to pursue - if it can be managed etc. What some
VPLS solutions are saying is that we have solved the
mesh problem by automating the provisioning -
excellent answer, and important. But another way of
solving the problem would be to provide a multipoint
server layer. That would leave three options for
service providers to choose from:

1. point-to-point transport to a client layer
switching function
2. edge-to-edge mesh that emulates a client layer
switching function
3. multi-point server layer

So then the question I would ask the WG, chairs, and
ADs is it acceptable to solve one problem along three
different (network)architectural paradigms, where you
have one solution per paradigm, or must we select one?
(we are of course looking like getting 1) and 2)
anyway so we will already have more than one); 

Why would we need both 2) and 3) well it may turn out
that solving QoS, traffic engineering, and management
problems are very complex to solve with 3) and
therefore 3) may give some charateristics which are
suitable for some service descriptions/operators but
not others.

Mark

---

From: [email-masked]
Date: Tue, 6 May 2003 21:14:24 +0100

Agreed Vasile...I see common *server* layer problems (assuming a given
server layer technology) being possible, but I see very different *client*
layer problems.  See my (far) larger posting to Alex for what is in my mind
here.
 
regards, Neil

-----Original Message-----
From: Vasile Radoaca [mailto:[email-masked]]
Sent: 06 May 2003 18:15
To: 'Loa Andersson'
Cc: Harrison,N,Neil,IKL2 R; [email-masked]; [email-masked];
[email-masked]

Loa, 

Cheers 
  Vasile 

-----Original Message----- 
From: Loa Andersson [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Tuesday, May 06, 2003 12:48 PM 
To: Radoaca, Vasile [BL60:X624:EXCH] 
Cc: [email-masked]'; [email-masked]; [email-masked];
[email-masked] 

Vasile, 

/Loa 

Vasile Radoaca wrote: 
>     From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ] 
>         From: Vasile Radoaca [ mailto:[email-masked]
<mailto:[email-masked]> ] 

-- 
Loa Andersson 

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

---

From: "Ron Haberman" <[email-masked]>
Date: Wed, 7 May 2003 09:44:15 -0400

Pedro,
Inline...

> From: Pedro Roque Marques [mailto:[email-masked]] 
> Sent: Tuesday, May 06, 2003 6:22 PM
> To: Ron Haberman
> Cc: [email-masked]
> Ron Haberman writes:
> > 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.
> 
> 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 ?

RH> I don't think that I should be grading to the WG :). In general
though, Masergy is relatively young company which helps it adopt new
technologies fast. I started planning for VPLS over a year ago, waiting
for the solutions to be agreed on. Do I think it could/should have been
done faster, sure, but that is almost always the case. 

As to the second part of your question, at this point all of the
technology that I am running in the network (for VPNs) came from PPVPN
and PWE3, 2575, martini and VPLS using lesserre-vkompella. That wasn't
the case in the past, we have adopted Juniper's CCC (before switching to
martini) using VLAN stacking (instead of label stacking that wasn't
available) to allow for reuse of LSPs. We had a short period of time
(never made it to the network) discussing VR based systems (which were
available) until 2547 came out.

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

RH> I was wondering about that myself. I don't understand why would
people voice concerns like that in private. From what I have seen, it
was possible to move at least one solution forward at the IETF in
Atlanta. Weather that would have made the WG more or less "successful" I
don't know. I think that in general terms there is a very fine line
between success that is based on finding solutions quickly and finding
the "best" solution possible. From the WG perspective I would think that
success is measured by:
1) Number of implementations of the technology (shows that competing
vendors agree on the solution).
2) Adoption of those implementations (shows that SP agree with vendors).
3) The solution/s become standard (provides a stamp of "approval" by a
certifying authority).
I assume that a lot of people will not agree and might want to rank (3)
as (1). I think that if as a SP I can offer a service using multiple
vendors and able to connect that service to other SP the technology
being certified "standard" is icing on the cake. That being said, I
would love for (3) to happen around the same time as (1) but I will not
wait.

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

RH> I am still hopeful that the new structure might not happen all
together. I think there is enough difficulty in coordinating efforts
between PWE3 and PPVPN. I also think that almost all people
interested/contributing to L2VPN will also be involved in L3VPN.

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

RH> I don't think it is my place to do that. I am part of the WG and
just like anybody else there are things that I personally think were
done right and wrong. I think most of the work was done in the "right"
way, people coming to agreement on solutions, working together,
collaborating, producing results. The only item that I would say was
done (and is being done) "wrong" is what appears to me as taking actions
based on politics driven by company's interests. Could that be avoided,
I doubt it. As much as the ideal of "personal contributions" makes sense
I understand it being very hard to follow when your company is in
competition with another to provide/sell the solution. As a general
improvement item to the IETF I would suggest to clarify the "voting"
procedures. At times my recollection of support or lack of was different
than the final decision (not just in PPVPN) not to mention that what
should the vote be in order to show support is by it self unclear.

> regards,
>   Pedro.

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Thu, 22 May 2003 15:40:39 -0400

Mark,

[clipped]...

> 
> To date we have asked the binary question of single or many. 
> Is there also
> some intermediate states?
> 

Yes! In fact the term 'solution' is misleading and can be
over-simplified to "one vs many protocols doing exactly
the same thing" which is, in my view, not the case here.

The situation today in l2vpns is a mixture between
three competing approaches in solving the l2vpn problem:

a) Developing a set of mechanisms as building blocks that
  can be used in multiple network scenarios for a given
  l2vpn service. In that context a 'solution' becomes
  a selection of a given set of mechanisms (specified
  independently).

b) Developing a set of independent vertical solutions that 
   meet a list of requirements (not all shared by all the 
   solutions) for a given l2vpn service. In that context a 
   'solution' is the approach that meets specific
   requirements important for *that* solution (whether the
   solution is built from architecturally decoupled
   mechanisms, etc is secondary as long as it meets
   the solution requirements).

c) Day one, select a set of mechanisms (with their protocol
   choices and standardize on one vertical solution).

Currently, the service requirements 
and framework documents, and some mechanisms are more
inline with a) while the existing solutions are more inline
with their specific problem/requirement space - since
they were developed *outside* (for most of them)
the framework&requirements drafts- (and we don't
have *solution requirements* besides the metric draft
which btw has expired!).

There were attempts in ppvpn to do a) instead of 
starting with b) but it didn't work out for many reasons
(not to mention here).  

Option c) was just recently introduced. The problem with it
is the fact we already have many vertical solutions that are
equivalent and address the problem from different angles.
And we don't have completely a set of clear,
decoupled mechanisms to use - I am not saying option c
is not achievable for some l2vpn services but I doubt
if this is achievable for all l2vpn services.

Personally I think given the current stage
of l2vpn work, we may need both a and b approaches. When possible,
one or many mechanisms should be developed to be used for one or many
reduced number of solutions while at the same time 'solutions' 
should be able to address requirements not necessarily shared
by all solutions and be open to accommodate/adapted to
common mechanisms.

Hamid.

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 27 May 2003 07:34:20 -0700

Folks,

I think that the following message is quite relevant to the discussion.

Yakov.
-----------------------------------------------------------------
Date:    Fri, 23 May 2003 10:04:39 EDT
To:      [email-masked]
From:    Frank Kastenholz <[email-masked]>
Subject: The One True Path To Nirvana

Folks,
I hate to inject a bit of reality into this but
whether the IETF decides to bless one-and-only-one
way to do FOO with the high-honor of "Standards Track
RFC" or allows multiple ways is only marginally
important.

Vendors, being interested in making money, try to
differentiate their products. The Offical IETF
Mantra in this regard is that vendor differentiation
arises out of things like quality. While true, it is not
the complete truth. Vendors will also have with their
own protocols as alternative ways to do FOO. The vendor's
marketing people will then tout their proprietary FOO
Protocol as "better" than the standard in various ways.
The proprietary FOO Protocol might even be what the 
vendor tried to get made a standard but failed (and
now there might be an installed base...)

Second, customers (bless their checkbooks and capex budgets)
sometimes what something that's not the standard. It could
have been something that was a candidate for standardizing
but didn't make it. It could be something that the customer
came up with. It could be some set of requirements that
the customer has (or thinks they have) that are not met
with the standard, requiring some non-standard-FOO.

Having multiple levels of standard really doesn't have
any effect on what vendors do or what customers want.
If the deltas from one level to the next are "just
bugfixes" then that's how they are treated by vendors.
If there are substantive changes in function (function-x
is available in proposed std, but not in draft, or vice
versa) then the implementation becomes the union of all
standard-levels, with config switches and the like. In other
words, the propose/draft/full hierarchy is little more than
feel-good self-gratification on the part of The Process Experts.

Btw, before I get roasted for heresy
a) There are always exceptions where things happen
   differently. When the right things happen, it's
   like winning the lottery. Enjoy it, but don't count
   on it
b) This is not a state of affairs that I find particularly
   desireable.  It is a state of affairs that does exist,
   however, and pretending that it does not exist is foolish.

So, the short answer is that multiple-competing-FOOs is
a fact of life. We live with it. We deal with it. Whatever
the IETF does, it will not go away. 

That said, what the IETF _can_ do is to make the problem
easier to deal with by
- getting the technical quality of things as high as we
  can as early as we can. That means -00 of the draft,
  if possible (yes, I know it won't happen, but the sooner,
  the better)
- getting drafts and changes and RFCs through the system
  faster (without sacrificing quality).
Ideally, -00 of the ID comes out 1 week after the first BOF
and there are no changes made to it, ever.

Frank Kastenholz

This is all my personal opinion and does not have anything to do
with what my employer says, thinks, does, etc.

---

From: [email-masked]
Date: Tue, 27 May 2003 16:15:01 +0100

Yakov

I think the phrase "Vendors, being interested in making money" from the
message below sums it up nicely;-)

Perhaps standardisation and interoperability may only be "marginally
important" to some large vendors that have the luxury of a large installed
customer base, or to some providers where a non-standard feature is the only
fix to a unique requirement.

However, I would suggest that for large operators looking at the
*possibility* of using MPLS as their next co pkt-sw core, standardisation
and interoperability would be extremely important. The L2 MPLS VPN solutions
are not just quick 'value add features' (which I think some people seem to
perceive them to be, due to the fact that they can be deployed using
existing networks and protocols with minimal changes).

L2 MPLS VPNs offer operators the *potential* to migrate existing co pkt-sw
services (i.e. ATM, Frame Relay) onto a single platform that one might
expect to be around for another 20 years or so to justify its investment. I
would suggest that proper standardisation (especially at the architectural
level) is a prerequisite for protecting this investment.

Richard

 > From: Yakov Rekhter [mailto:[email-masked]]
 > Sent: 27 May 2003 15:34
 > To: [email-masked]; [email-masked]