Re: Single vs many solution(s)

Alex,

>  Thanks for your input, it is indeed very important for us to be on
>  the same page here, and I happen to agree with most of what you said.
> 
>  I don't think that "solution" == "protocol", but rather a set of
>  functional components, each addressing its particular problem. The
>  framework would then put them all together.
> 
>  I also view as reasonable an approach where there is a difference
>  between how intra-domain and inter-domain issues are solved.
> 
>  So, from this perspective, the framework MAY very easily look
>  like this (mechanism == protocol or protocol extension):
> 
>   Data-plane              : mechanism A
>   Intra-domain discovery  : mechanism B
>   Intra-domain signaling  : mechanism C
>   Inter-domain discovery  : mechanism D
>   Inter-domain signaling  : mechanism C++
> 
>  Of course there must be some architectural glue that brings all
>  the pieces together.
>   
>  What I would like us to avoid is solution space exploration, where
>  we have many mechanisms for the same function we need, i.e, I would
>  be disappointed to see us end up with a framework looking like:
> 
>   Data-plane              : mechanism A, or B, or C
>   Intra-domain discovery  : mechanism D, or E, or F
>   Intra-domain signaling  : mechanism G, or H, or I
>   Inter-domain discovery  : mechanism J, or K, or L
>   Inter-domain signaling  : mechanism M, or N, or O
> 
>  This would, in view, impact interoperability.

To avoid disappointing you the WG immediately needs to start the
discussion on whether to use L2TPv3 encapsulation or MPLS or MPLS
over GRE, or MPLS over IPSec.

Likewise the WG immediately needs to start the discussion on L2TPv3
vs LDP based signaling.

Likewise, the WG immediately needs to start the discussion on BGP
vs Radius based auto-discovery.

Yakov.