RE: Single vs many solution(s)

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.