Re: Single vs many solution(s)

Richard,

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

One of the lessons we have learned from "CR-LDP vs RSVP-TE debacle"
is that when presented with multiple solutions, selecting one
of them based on the  working code + operational experience is 
much more productive than based on the debate within an IETF WG.

> Lets not repeat it for L2VPN.

Agreed. Yet some folks really seem to insist on repeating it...

Yakov.