RE: Single vs many solution(s)

Loa,

> 
> 1. so far I've seen multiple solutions aiming to solve the same
>     problen, e.g. the vkompella vs. kkompella discussion
> 
<snip>...

> 
> So until someone proven that that e.g. the kkompella and vkompella
> addresses different problems I will try to make the wg adopt only one.

<snip>....

> 
> Any volunteer to try describe the problem space(s)?
> 

I think since vkompella vs kkompella discussions (or more precisely
kkompella discussions) we have been moving from
one issue/topic to another not related to the drafts themselves and
if I summarize the item we can list:

a) Are there strong *technical* issues with kkompella proposal?

  There was a debate, the draft is now WG document so I assume
  the chairs and ADs concluded that there are no major technical issues 
  stopping the WG to work on the proposal. So let's move on from
  that item.
  
b) Should the WG work on more than one distinct solution
   for the same problem (problem == l2vpn service)?

   Given a) and adopting other drafts the answer is yes. 
   In fact we also indirectly debated that since IPLS and VPLS provide 
   the same "service", then a potential question is 

   "Should the wg consider IPLS and VPLS
   as solving the same problem or different problems?" 

   If it is the same problem should the wg focus only on VPLS (as a 
   superset service)? or should the WG treat l2vpn services
   for IP host/routers-based CEs as different l2vpn services?
  
c) Should the solutions all progress as PS or experimental?
   
   It looks to me it is premature to debate that item at this
   point in time.

d) Do we need multiple mechanisms for the same problem?
   (e.g., Radius and BGP discovery)?

   In my view this question should be contrasted to the approach taken 
   in solving the l2vpn problem and the requirements
   addressed in the solution. There are problems that
   are services and there are those that are mechanisms.

   Since we are working on a per-solution style, it is logical that 
   protocol choices made in one solution may not be acceptable to 
   others or will not meet the requirements for other solution. In that
   respect having multiple mechanisms (using multiple protocols)
   to be used in one or more solutions is a consequence
   of both the approach taken and the reality of ppvpn problem space
   -as being 'provider-centric technology/services' instead of
   being only 'protocol-centric' problem. Therefore I don't
   see the value of addressing this item (nothing wrong 
   discussing the technical aspects though).

e) Concerns on the use of BGP (routing protocol) for implementing
   VPN functions.

   Using BGP for implementing VPN functions is a valid approach 
   and so far since l3vpns we know about the applicability of 
   BGP-based mechanisms in the field more than any other mechanism. 

   It looks to me Yakov's request to put clearly on the table
   the IESG concerns (if any) for this item is a reasonable request. 
   That will allow the WG to debate the items that are really of 
   concerns or need to be addressed and highlighted..and that will just
   improve the quality of wg outputs. 

<snip> 

> BTW - I suggest tht we start dropping copies to the ppvpn-list for
> anything that is not vpn generic.
> 

If I am not mistaken, I think the debate on l2vpn mailing list is on 
the charter only.

Hamid.